Using stack "On startup" does not work. - (in IDE)

[DR White]

I am trying to use "On startup" in my stack instead of "openStack" but it is not initializing my variables with the starting values like "openStack" did. Doesn't "On startup" initialize when the message is "Sent to the first card opened when the application starts up." as stated in the dictionary?

[dunbarx]

Hi.

Is this in the IDE or in a standalone?

Craig

[DR White]

It is in ide

[bogs]

I'm not sure you would see it work in the IDE, depending on how your testing it.

The dictionary says -

The startup message is sent only when the application starts up, not when a stack is opened when the application is already running.

In the IDE, the application would already be open, if you see what I mean. Aside from that, the IDE has already passed startUp, so even if you completely closed your project, the IDE would be hosting it.

I could be wrong though, hopefully someone else knows better.

[dunbarx]

Well, I have never used this in LC, though I used to in HC.

In the IDE, with a new stack of one card with this in the card script:

Code: Select all

on startup
   answer random(999)
end startup

In a new session starting LC from the desktop by opening that stack, nothing happens. In a sense, "preOpenWhatever" ought to do much the same thing, since "startUp" is sent to the first card of a stack opened in a new session, and we always know what stack that is.

It might be interesting to have that handler in an "application" frontScript, so the user can know which stack was opened in a new session:

Code: Select all

on startUp
  answer the name of this stack

but one has to already have a session open in order to insert a handler "into front" in the first place. I assume I am right in thinking there is no way to do that?

Anyone?

Craig

[bogs]

I'm not sure you would see it work in the IDE, depending on how your testing it.

I should have expanded on this,

IF you have the startUp handler in the SE, you can execute that handler specifically, and it should work.

[Thierry]

The startup event is consumed by the IDE in the stack home.livecodescript
and not available to IDE Users. That's the first event thrown by the engine
when you start an app ( the IDE is an app).

In case you don't believe me:

startup in home.livecodescript

Regards,

Thierry

[DR White]

Thanks Thierry for clearing that up.

[DR White]

Is there any problems to using the old "openStack" and "preOpenStack"?

[FourthWorld]

Well, I have never used this in LC, though I used to in HC.

In the IDE, with a new stack of one card with this in the card script:

Code: Select all

on startup
   answer random(999)
end startup

In a new session starting LC from the desktop by opening that stack, nothing happens.

It may seem counterintuitive, but LC and HC are working the same here.

The rule is that the startup message is sent to the first card in the first stack file the engine is asked to open after launch.

In HC, the IDE is written in a compiled language and embedded within the engine, so the first stack file encountered is the user stack you double-clicked.

In LC, the language is complete enough that the IDE is written in LC itself, so if you want to open it with the IDE you'll find that the IDE stack files are the ones it encounters first.

In terms of design goals, this fits the needs of both models:

HC initially had no means of producing standalone applications, so the development environment had to serve double duty as the deployment environment as well.

LC comes with a dedicated development environment, with deployment being either binding the engine to your stack file into a standalone, or making a sort of player app that can open external stack files (what some call a "splash stack" pattern, though I prefer to keep the splash stack modifiable along with everything else within the external stack file).

This difference is more than a testimony to the richness of LC as one of only two xTalks I'm aware of that has the confidence in its own language to use it for its own IDE. It also provides us with an opportunity to differentiate initialization tasks we want handled only in a true deployment environment.

If you have init you want to happen in both dev and runtime, put those statements in a preOpenStack handler in the first card of the mainstack.

[DR White]

But I don't want perform the logic every time I open and close my first card.

I suppose I could have my first card be a "Splash" type card and never see it again while the application is running, but that is a lot more work than using the old "OpenStack". Without "PreOpen", where would I set my "fullscreenmode"?

[stam]

But I don't want perform the logic every time I open and close my first card.

Sorry if i got the complete wrong end of the stick, but openStack and preOpenStack won't run every time you open/close the first card, just the stack no?

If there is a different issue that passed me by, you could also maintain a script variable as a boolean that gets set to True the first time the script runs and then check if true don't run the script again?

[FourthWorld]

We can work out the messaging mechanics easily enough; I often use an init flag to handle such cases.

But with the desire to use LC as both a development and deployment environment, I have to ask: What is fullscreenmode doing for you in the IDE?

(Another question might be what it's doing for you in deployment, given its highly specialized nature, but that's another topic.)

[DR White]

I don't use fullscreenmode in the IDE.

The only reason I use IDE is to test the mobile app. Right now I can't run the iOS simulator until LC version 9.6.3 comes out to be compatible with my Xcode 12.4

[FourthWorld]

Without "PreOpen", where would I set my "fullscreenmode"?

And:

I don't use fullscreenmode in the IDE.

Problem solved?

PreOpenStack is only sent once, when the stack is opened. Going card to card will not trigger it again.