Jacqueline gave me a really slick solution to my problem off list. He is
what I am going to use in the next release of the MasterLibrary:
on preopenstack
send "Mark_IDE_done" to me in 2 ticks
go to cd "Splash"
end preopenstack
on Mark_IDE_done
try
get revloadedstacks()
catch err
send "Mark_IDE_done" to me in 2 ticks
exit to top
end try
go to cd "LibMgr"
end Mark_IDE_done
This is so simple, I really don't care about delaying for the whole IDE
to be finished. I only need a single function to be available. This
works like a charm.
Regards,
Mike
On 12/28/14 4:24 PM, Mike Bonner wrote:
No suggestions really, because i'm not sure whats going on (he says, as he
gets ready to make suggestions anyway).
It seems that since all the plugins are a part of the sequence in that
handler I mentioned, and that plugins are loaded before the allowinterupts
is set, it seems that you'd end up with false at the start, and false at
the end, due to the plugins causing a problem. I'll look at the code again
(tomorrow, today is on overload for me) and see if I can figure out where
that log is kept, (others probably know off the top of their heads) perhaps
there is a logged clue in there somewhere.
Richard, yep, that does throw a kink into my understanding. Off to read up
on things.
As far as whether it is necessary to go to this trouble to discern the
state of the IDE, I gotta ask (as J has) does a simple send in time work?
If you display the counter as part of your messages, i'm pretty sure its
always 1, meaning the 2 ticks delay you use is plenty. And I suspect that
sending in 0 would work also, (unless the idle thing mentioned by Richard
is getting in the way). In addition, would it work to put it into
openstack or opencard? Since they occur after the pre in the sequence of
things.
I think if it were me, I'd still pursue the plugins line of query also,
just to figure out why the allowinterrupts is misbehaving, but would look
for a simpler way to fix the initial issue.
On Sun, Dec 28, 2014 at 12:20 PM, J. Landman Gay <jac...@hyperactivesw.com>
wrote:
On 12/28/2014 12:44 PM, Michael Doub wrote:
Note that the OpenStack message is received before the initialization of
the IDE has completed so when the revloadedstack function was called, it
was not found. if you look at the IDE home stack, you will see the
interrupts are blocked until all of the IDE initialization is completed.
I think that some of your assumptions regarding the loading of stacks
may be incorrect. This is clearly showing that a users stack does in
fact start execution before livecode initialization is completed.
The other interesting thing to note is that I found a plugin that looks
like it was setting allowinterrupts to false and never setting it back
to true. I put that counter in the Mark_IDE_done handler so it would
not fire forever as I was debugging. Anyway, I sent off an email to the
developer of the plugin to start the discussion with him off line.
I hope this clears things up for you.
Not entirely. It shows how you tested the message order, but not what you
want your script to do or what your final goal is. Or are you just trying
to find out which LC stacks are open?
It does look like I was wrong about the sequence specifics. But however it
works, I think many of us use a delayed call to do something after the IDE
is done launching. Whatever your final goal is, it seems it could be more
easily done with this:
on openStack
send "myHandler" to me in 1 second
end openStack
on myHandler
-- do actions here
-- if the goal is to see which stacks are open, query revloadedstacks
here
end myHandler
By the time myHandler triggers, the IDE is loaded. If you think it may
take longer on slow machines, use 2 seconds. Put the handlers on the first
card, so that openstack won't trigger more than once.
I'll admit this is a sort of fuzzy workaround, so your request for a new
engine message is probably useful. But until we get that, the above seems
to work.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
