How to know if a substack's script has finished loading?

[Zax]

Hello,

Is there a way to know if a substack's script has finished loading? Something like a message that could be intercepted in a callback.
I use the following structure in my stacks:

Code: Select all

on preOpenStack
   insert the script of stack myCustomErrorReportStack into front // a substack
   insert the script of stack myLibraryStack into back // another substack
   send "prefsRead" to me in 100 milliseconds ///// arbitrary value!
end preOpenStack

on prefsRead // read app preferences
   callToLibraryCommand // a command defined in myLibraryStack substack
end prefsRead

The problem here is that the arbitrary value (100 milliseconds) needed to allow scripts to load depends on the user's machine - mainly their disk type and processor I suppose. This value could sometimes be reduced to speed up main stack loading, and sometimes turns out to be too low, and it leads to a critical error if I call prefsRead too early.

Thank you.

[richmond62]

I did something very simple, and it may not suit your needs, but here goes anyway.

I made a stack "Home Stack" and a substack "Subordinate",

AND I put this in the script of a button on stack "Home Stack":

Code: Select all

on mouseUp
   put empty into fld "fDONE"
   open stack "Subordinate"
end mouseUp

and I put this into the stack "Subordinate":

Code: Select all

on openStack
   set the left of me to ((the right of stack "Home Stack") + 20)
   set the top of me to the top of stack "Home Stack"
   wait 10 secs
   put "Finished" into fld "fDONE" of stack "Home Stack"
end openStack

The reason I put a 10 second wait in there was to simulate a long and complicated openStack script.
-

-

[LCMark]

Is there a way to know if a substack's script has finished loading? Something like a message that could be intercepted in a callback.
I use the following structure in my stacks:
...

The scripts inserted by the 'insert' command will be in the message path as soon as the insert command finishes (unless there's a syntax error in the script in which case it won't). i.e. There is no 'threading' or async stuff going on.

Specifically, if 'callToLibraryCommand' is a handler in one of your back or front scripts, it can be called immediately after the insert.

The problem here is that the arbitrary value (100 milliseconds) needed to allow scripts to load depends on the user's machine - mainly their disk type and processor I suppose. This value could sometimes be reduced to speed up main stack loading, and sometimes turns out to be too low, and it leads to a critical error if I call prefsRead too early.

If that is the case then it is something in your code which is doing something 'in time' on startup and needs to complete for your code to work correctly - so you should be able to make that 'callback' when whatever it is doing is done so that your app startup to continue (i.e. no need for an arbitrary 'wait').

[Zax]

Thank you for your answers.

The scripts inserted by the 'insert' command will be in the message path as soon as the insert command finishes (unless there's a syntax error in the script in which case it won't). i.e. There is no 'threading' or async stuff going on.

Specifically, if 'callToLibraryCommand' is a handler in one of your back or front scripts, it can be called immediately after the insert.

I forgot to specify that I only encountered this problem in the standalone versions.

If that is the case then it is something in your code which is doing something 'in time' on startup and needs to complete for your code to work correctly - so you should be able to make that 'callback' when whatever it is doing is done so that your app startup to continue (i.e. no need for an arbitrary 'wait').

OK, I'll check my startup process.

[LCMark]

@Zax: Are you using any inclusions in your project? In particular what is the critical error you are receiving in prefsRead?

There’s an internal startup script which is added to standalones which ensures all the things you specify in standalone settings inclusions to be loaded and initialised.

I don’t think there any ones we provide which don’t startup immediately so it could be a third party one causing your issue potentially.

[stam]

Out of curiosity, could it be something like revCopyFile/revCopyFolder, which requires the common library that has be loaded first?

Note: In a standalone application the Common library is implemented as a hidden group and made available when the group receives its first openBackground message. During the first part of the application's startup process, before this message is sent, the revCopyFile command is not yet available. This may affect attempts to use this command in startup, preOpenStack, openStack, or preOpenCard handlers in the main stack. Once the application has finished starting up, the library is available and the revCopyFile command can be used in any handler.

I know this was an issue for me when on startup the app would check for preferences and if none found would copy the default folder and documents to the preferences folder. I had to move this to the openCard handler of the slash screen instead...

[Zax]

@Zax: Are you using any inclusions in your project? In particular what is the critical error you are receiving in prefsRead?

In my example, the error would be that "callToLibraryCommand" is not recognized/handled - makes sense if the call comes too early and myLibraryStack is not already loaded.

Most of my apps use these inclusions:
- tsNet
- spinner
- datagrid
- cursors
- ask and answer dialogs
and sometimes : XML

[stam]

@Zax: Are you using any inclusions in your project? In particular what is the critical error you are receiving in prefsRead?

In my example, the error would be that "callToLibraryCommand" is not recognized/handled - makes sense if the call comes too early and myLibraryStack is not already loaded.

Most of my apps use these inclusions:
- tsNet
- spinner
- datagrid
- cursors
- ask and answer dialogs
and sometimes : XML

Perhaps it would be useful to include the handler for callToLibraryCommand here?

The other thing to consider is to include a callback from the myLibraryStack's libraryStack command, so that callToLibraryCommand is triggered from that (i.e. after the library as loaded)

[LCMark]

@stam: Librarystack is sent immediately after the script is loaded with ‘start using’ and isn’t delayed so that wouldn’t make a difference here.

The common library thing could be a thing - except that the hidden group thing was change quite a while ago - things like common library should be inserted by the internal startup script before any user script runs (however as you have clearly had a problem there presumably in recent history we will check whether that is still a problem!)

@zax: That error can hide an actual error - if whatever is failing is called directly from that handler and it isn’t pushing an error then it can manifest as a ‘cant find handler’ error so seeing the code of the handler which is failing would help.

[Zax]

Well, I just removed the delays (send with...) from my opening script, recompiled and it works correctly in standalone environment
Anyway, I now have a better understanding of what happens at startup. If my "cant find handler" problem comes back, I will post the code.

Thank you for your answers.

[Zax]

The scripts inserted by the 'insert' command will be in the message path as soon as the insert command finishes [...]

Specifically, if 'callToLibraryCommand' is a handler in one of your back or front scripts, it can be called immediately after the insert.

I currently don't have enough time to do in-depth testing, but there is still something I'd like to be sure of.
Concerning a standalone app, if I write:

Code: Select all

on preOpenStack
   insert the script of stack myLibraryStack into back // a substack
   callToLibraryCommand // a command defined in myLibraryStack substack
end preOpenStack

Assuming myLibraryStack is a fairly heavy substack, with lots of images, it might take a few ticks before it's really up and running.
Is the "insert the script of..." a blocking command in a standalone? Is the current handler frozen until the script finishes loading?

[jacque]

If it's a substack then it's already loaded. LC loads all stacks in the stack file when the mainstack opens. Inserting a script is just a tweak to the message path and should be nearly instantaneous.

[Zax]

OK, thank you Jacqueline