How to tell when IDE is done loading

Michael Doub mikedoub at gmail.com
Sun Dec 28 19:38:49 EST 2014


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 <jacque at 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         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>





More information about the use-livecode mailing list