How to tell when IDE is done loading

Mike Bonner bonnmike at gmail.com
Sun Dec 28 11:02:32 EST 2014 

Things are working correctly for me. 7.0.0, (since 7.0.1 still won't
install) When starting up the stack and IDE by opening the stack,false is
first.  After the IDE is fully open, allowinterupts seems to always be true
for me.

Not managing to duplicate the problem so far. I did adjust things so that
the ctr variable gets set to the message box too during the send loop, and
its always 1, which seems to indicate a simple send in time should be
sufficient. (send whatever to me in 0). Unless there is a "wait with
messages" somewhere along the line in that big startup handler I mentioned
in the previous post, the send that you do should be dumped at the end of
the queue and not fire until things are done.  (this is how people have
been getting around library loading problems.  Either a send to place the
call at the end of the queue, or using openstack or opencard instead since
they happen slightly later.)
IF you're getting allowinterups = false AFTER the IDE is fully open, (or
seems to be) something funky is going on.  Do you have any plugins?  Can
you take them out of the equation for now, then add them back in one at a
time?  That handler I mentioned also does copious logging, you might be
able to track down where the log is, and look at it.

On Sun, Dec 28, 2014 at 8:29 AM, Michael Doub <mikedoub at gmail.com> wrote:

> Jacqueline, I do think that there is a timeing issue that you have to be
> aware of if you a calling revloadedstacks.
> But something strange _IS_ going on.
>
> Please create a stack and enter the script below into the stack script and
> save the stack and quit livecode.   Doubleclick on the stack icon.
>
> You should see...
>
> false
> preOpenStack
> true
> Startup Complete
>
> This is the expected behavior.   Note that the preOpenStack handler is
> called before the IDE home stack has finished initialization. This can
> clearly be seen if you watch the message box closely.
>
> Now close the stack and remove it from memory and then open the stack.   I
> do not get the expected behavior.  It seems that allowinterupts is set to
> false.   I get false on a clean start of livecode and checking
> allowinterrupts from the message box too.
>
> Can you confirm what I am seeing or explain what is going on, or have I
> found a bug?  it appears to me that somewhere in the IDE, allowinterupts is
> being set to false again after the main startup code in the home stack
> resulting in the default state to be incorrect.
>
> Regards,
>    Mike
>
>
> local ctr
>
> on preopenstack
>    put the allowinterrupts & cr
>    send "Mark_IDE_done" to me in 2 ticks
>    put "preOpenStack" & cr
> end preopenstack
>
> on Mark_IDE_done
>    add 1 to ctr
>    put  allowinterrupts & cr after msg
>    if allowinterrupts = false then
>       if ctr < 25 then
>          send "Mark_IDE_done" to me in 2 ticks
>       end if
>    else
>       put "Startup Complete" & cr after msg
>    end if
> end Mark_IDE_done
>
>
>
> On 12/27/14 11:29 AM, J. Landman Gay wrote:
>
>> I'm confused. LiveCode knows how to open a stack as part of its startup
>> routine. Since  card 1 is always opened first, a preopenstack handler there
>> will always fire and you can do your setup there from that card without
>> worrying about timing.
>>
>> On December 27, 2014 10:12:19 AM CST, Michael Doub <mikedoub at gmail.com>
>> wrote:
>>
>>> Jacqueline and Mike, thanks for you help with this.
>>>
>>> Just to clarify,  I am trying to solve the problem in the environment
>>> where livecode is not running and the user double clicks on the
>>> MasterLibrary stack.   This is not a standalone program but a stack
>>> that
>>> is being started from the desktop.  I am testing on a Mac, but I need
>>> to
>>> test on a PC to see if the behavior is any different.
>>>
>>> Mike, I think you gave me a great clue.   The current logic in the
>>> MasterLibrary is one where the preopenstack handler puts up a splash
>>> screen and sends off a wakeup message to come back in 5 seconds.  I was
>>>
>>> quite surprised to see how long it actually took the IDE to get
>>> initialized.  This is way too long to wait if livecode is already up
>>> and
>>> running.
>>>
>>> I added some debug code to display the allowinterupt state and found
>>> that at the time my preopenstack handler messages gets called
>>> allowinterupts is false, but in my wakeup hander the allowinterupts is
>>> true.  This leads me to believe that I can monitor the allowinterupts
>>> at
>>> a faster frequency and do the actual wake up processing when I see it
>>> go
>>> true.
>>>
>>> Regards,
>>>      Mike
>>>
>>>
>>> On 12/26/14 4:38 PM, Mike Bonner wrote:
>>>
>>>> It looks like the IDE load order is this:
>>>> System params are checked
>>>> libraries loaded
>>>> globals set
>>>> preferences set
>>>> icons loaded
>>>> patterns loaded
>>>> script editor loaded
>>>> user icon libraries loaded
>>>> error management loaded
>>>> tools loaded
>>>> menu bar loaded
>>>> app overview loaded
>>>> message box loaded
>>>> debugger loaded
>>>> quicktime loaded
>>>> plugins loaded
>>>> then "revInternail_InitializeFinalSteps..
>>>> after that, there are still a couple things such as checking the
>>>>
>>> license
>>>
>>>> being used (community etc) and setting some os specific parameters.
>>>>
>>> The
>>>
>>>> very last thing (it seems) is the line "set the allowinterrupts to
>>>>
>>> true"
>>>
>>>> You can see this info in the script of stack home.rev, handler
>>>> revInternal_openStack.  Wonder if there is something in that script
>>>>
>>> you can
>>>
>>>> check to determine if the IDE is far enough along to do the things
>>>>
>>> you
>>>
>>>> need.
>>>>
>>>>
>>>> On Fri, Dec 26, 2014 at 1:31 PM, J. Landman Gay
>>>>
>>> <jacque at hyperactivesw.com>
>>>
>>>> wrote:
>>>>
>>>>  On 12/24/2014 11:57 AM, Michael Doub wrote:
>>>>>
>>>>>  I have tried that but I need to process the resumeStack message
>>>>>>
>>>>> which
>>>
>>>> seems to get called as part of the startup process.
>>>>>>
>>>>>>  Resumestack shouldn't be sent normally when a stack opens. There's a
>>>>> difference between starting up a standalone and starting the IDE
>>>>>
>>>> though; it
>>>
>>>> may be that some of the IDE stacks need to deal with resumestack.
>>>>>
>>>> But your
>>>
>>>> own stack shouldn't need to.
>>>>>
>>>>>    I guess I have to
>>>>>
>>>>>> manually set a global flag and have the timed handler unblock the
>>>>>> flag.   What is the very first handler that an application can
>>>>>>
>>>>> process?
>>>
>>>> Startup?
>>>>>>
>>>>>>  Again, it depends. In a standalone the first message is startup. The
>>>>>
>>>> stack
>>>
>>>> isn't fully loaded at that point so you can't manipulate stack or
>>>>>
>>>> card
>>>
>>>> objects yet but you can set global properties there.
>>>>>
>>>>> But in the IDE, LiveCode itself catches the startup message and your
>>>>>
>>>> stack
>>>
>>>> will never receive it. The first message your stack will get is
>>>>> preOpenStack.
>>>>>
>>>>>
>>>>>    Is there an ordered list of messages that are fired for startup
>>>>>
>>>> and
>>>
>>>> opening a stack?  Opening a card would be useful too.   I can't say
>>>>>>
>>>>> that
>>>
>>>> I have ever seen this anywhere in the documentation.
>>>>>>
>>>>>>  It follows the normal message path in reverse, starting with the
>>>>>
>>>> stack
>>>
>>>> messages followed by background group messages and then card
>>>>>
>>>> messages. If
>>>
>>>> there are card groups on the first card, they get sent last.
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>>  _______________________________________________
>>> 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