Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5542 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

Got it! It was a rogue script step. I seem to be able to 'get' the answer once I ask for help... hmmmmm

The startup layout has a script trigger 'On Layout Load' referencing a script that resizes the layout to 280 x 380.

When FM is running and I DOUBLE CLICK THE .FP7 file the program starts as expected and the layout is resized accordingly.

However, if I close that instance and choose FILE/OPEN RECENT I get a much larger window that was previously shown.

Also, if I click the OK button on the smaller first layout it takes me to a larger input layout. If I exit my program from that larger input layout and then restart by double clicking the .fp7 file I get the intro/smaller windows but it is NOT resized to the smaller size. It appears to be the larger size of the input window.

This behavior is driving me nuts. If anyone has any ideas of what is going on I would really like to hear about it.

thanx

Edited by Guest
Posted (edited)

I have 2 layouts.

Layout #1: Called ACTIVATION

It is a small 300 x 200 layout used for activation of the app.

Layout #2 is called Input

It is larger about 500 x 400 in size and is one of the main functioning layouts

I have a script called STARTUP which is called when the app starts.

There is also a script called INPUTLOAD which is called as a script trigger when the INPUT layout in loaded.

There is a script called ACTIVATION_LOAD which is called when the Activation layout is loaded.

STARTUP script does some evaluation and then takes the user to the Activation layout so the user can enter their activation key or press OK to continue in Demo mode.

After OK is entered, the user is taken to the INPUT screen

debug-full;init:.jpg

PROABLEM:

If the user exits the app from the input layout, when the app is started again, STARTUP script is run and then it runs the INPUTLOAD script?:

Specifically, I have seen this in debug mode: When the STARTUP script is loaded, Debug shows 2 scripts at the bottom of it's window The first is STARTUP and below it is INPUTLOAD. Even though I call the ACTIVATION layout from startup, when it is finished it then runs the INPUTLOAD script.

It seems as if FM is running INPUTLOAD script because that was the last layout open when closing and it therefore puts that load script in the que after startup?????

What I want to happen is to just run STARTUP script and no other 'residual' script. Do I have to flush a cache or something?

What do you think????

Edited by Guest
Posted

Perhaps non of these globals have values? I assume that this is for a runtime and will run single-user, and so the globals will have the last stored value when run in single user. Anyway, if I read your script and the globals aren't what you think they are, you fall thru to the Go to Layout "Input," and your onLayoutLoad fires.

I recommend storing the default values for these globals in a PREF table and explicitly setting them in your open script.

Posted (edited)

post a demo, and this should have been posted to your existing thread. I've merged the two topics

Edited by Guest
Posted

Perhaps non of these globals have values?

[color:blue]All this is in the STARTUP SCRIPT.

The globals are used in the varification process. ie, if the app has never been started before, a global is set to 0 and the app serial is generated. Afterwords that global is set to 1 and when tested on the next strtup does NOT generate a new serial. Same with the others.

I assume that this is for a runtime and will run single-user, and so the [color:red]globals will have the last stored value when run in single user.

[color:blue]True. The app is being run as single user and the fact that the globals will have the last value is what is intended. (see the tests above)

Anyway, if I read your script and the globals aren't what you think they are, you fall thru to the Go to Layout "Input," and your onLayoutLoad fires.

[color:blue]Not really. The globals perform tests on the state of the app. ie, registered, demo, first run etc... If the app is registered with a valid serial ID, then the app goes to the INPUT layout. Otherwise it goes to the ACTIVATION layout.

The problem is that if the user exits from the INPUT layout, when the app starts, the STARTUP SCRIPT shows 2 scripts. Startup AND the script that is run when INPUT LOADS.

I recommend storing the default values for these globals in a PREF table and explicitly setting them in your open script.

[color:blue]I have the global values stored in a GLOBALS table. Isn't that the same thing?

Posted

What I mean is don't use globals as you would non-global fields. Store the values in non-global fields (typically in a Pref table) and explicitly set them in your startup script.

For example, the part of the Startup that I see has a condlt, If g.flag=0. When is g.flag set? I would have this flag in a number field and set it in the startup. Also, using a period in a field name is not best-practice. Use underscores instead, "g_flag." Also, a common mistake is forgetting to set the storage to global.

Maybe you should post the entire script?

Posted

The crux of my lack of understanding centers around the fact that 2 scripts show in the bottom of the debug window. The first is called when the app starts but the second ????

So, I changed the app file startup to run a script that loads the ACTIVATATION layout which 'on loading' runs the STARTUP SCRIPT.

But, even in this scenario, debug reveals that the [color:red]startup script is also run twice?

:

There is something pretty fundamental I am missing but I can't see it.

Thanks for reading....

Posted

I'm out of guesses. Please post a clone. Also, I would never have a Startup script run onLayoutLoad. By definition, it should run once...on Startup!

This topic is 5542 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.