openStack problem

[Rob van der Sloot]

There is one thing about the openStack message I don't understand.

I have a main stack with a number of substacks.
With the openStack message I go to a specific layout etc.

on Openstack
show stack "....."
set the width of this stack to 781
set the height of this stack to 543
set the loc of this stack to 872,507
go to card "Login"
send "CheckStack" of card "Login"
end Openstack

Then after that the mainstack is directed to a card where there are some buttons.
These buttons are opening other substacks and go to a card of that substack and do some other tasks

on mouseUp
global gPeopleLabel, gComLabel, ctID, bgID, gBookingLabel
global gDay, gMonth, gYear
put Line 2 of field "Peoplelabel" & "," & Line 1 of field "ComLabel" into gPeoplelabel
put the label of button "Day" into gDay
put the label of button "Month" into gMonth
put the label of button "Year" into gYear
send "DiagnoseOpen" of stack "Diagnose"
end mouseUp

This works ok, but the first time I click the button, LC is going up the hierarchy and performs the OpenStack message from the mainstack. The substack screen is show in the screen of the mainstack, so there are 2 things confusing each other.
This happens after the forth command line of the script "DiagnoseOpen". This line says "show stack Diagnose".
There I don't understand why this happens and what to do to prevent this.

on DiagnoseOpen
global ctID, bgID, gPeopleLabel, gComLabel, gBookingLabel, tShow
global gDay, gMonth, gYear
lock screen
show stack "Diagnose"
......
....
end DiagnoseOpen

Please some advice on this.

thanks
Rob

[LiveCode_Panos]

Hi Rob,

What about putting the "openstack" handler in the first card of the mainstack? In that way, it will fire only the very first time you open your mainstack, and not every time you visit a substack of the mainstack.

Best,
Panos
--

[Rob van der Sloot]

Yes, that works as I wanted.
Thanks very much

[dunbarx]

Rob.

This is common practice, to "localize" initialization processes to a certain stack. This by putting the handler in the "lowest" possible object in the message path that still does what you need, instead of what seems like the most logical place, which may be too high, too "accessible", for some purposes.

Craig Newman