openStack problem on 4.5.2 substack

[kwinkler]

I finally got my app working correctly, so I bought the commercial license, which also upgraded me to LiveCode 4.5.2. Now I have a new error.

Whenever I open a particular substack, the openStack function of the MAIN stack runs. This is not desirable. Another substack does not have this problem. If I use LiveCode 4.5.1, the problem goes away.

The problem substack only has a dataGrid on it. It has its own openStack function that references some global variables that are also used by the main stack. But this shouldn't cause the MAIN stack openStack function to run.

For now I'm back to 4.5.1. Any thoughts about what is going on would be appreciated.

[Klaus]

Hi kwinkler,

this should not happen and does not happen usually!
At least I did not experience this in the last 11 years

So there might be something in the "openstack" script of your substack,
could you please post the script?


Best

Klaus

[kwinkler]

Hi Klaus,

Here is the stack script from the substack (called dataStack) that has a problem. I don't see anything here that would run the openStack script of the main stack. And as I said, this works fine in LiveCode 4.5.1.

Thanks for any insights.

Ken


global allDataArray,numyears,Expenses,IncomeCTE,SocialSecurityCTE,PensionCTE,TaxAssetsDrawDownNet
global TaxDeferredAssetsDrawDown,TaxableAssets,TaxDeferredAssets,TotalAssets,Age,Year,TaxTotal

on OpenStack
repeat with p= 1 to numYears
put Age[p] into allDataArray[p]["Age"] -- also put it into allDataArray
put Year[p] into allDataArray[p]["Year"]
put the round of Expenses[p] into allDataArray[p]["TotalExpenses"]
put the round of IncomeCTE[p] into allDataArray[p]["ExpensesFromIncome"]
put the round of SocialSecurityCTE[p] into allDataArray[p]["ExpensesFromSocialSecurity"]
put the round of PensionCTE[p] into allDataArray[p]["ExpensesFromPension"]
put the round of TaxAssetsDrawDownNet[p] into allDataArray[p]["ExpensesFromTaxableAssets"]
put the round of TaxDeferredAssetsDrawDown[p] into allDataArray[p]["ExpensesFromTaxDeferredAssets"]
put the round of TaxableAssets[p] into allDataArray[p]["TaxableAssets"]
put the round of TaxDeferredAssets[p] into allDataArray[p]["TaxDeferredAssets"]
put the round of TotalAssets[p] into allDataArray[p]["TotalAssets"]
put the round of TaxTotal[p] into allDataArray[p]["Taxes"]
end repeat

--put the round of TaxableAssets[0] into allDataArray[0]["TaxableAssets"] --mainly for debugging

put 0 into allDataArray[0] -- activate this line in the final product so table begins with StartAge

set the dgData of group "myDataGrid" on card "dataCard" on stack "dataStack" to allDataArray -- load Data Grid
end OpenStack

[Klaus]

Hi Ken,

hmmm, nothing unusual what could cause this.
Sorry, no idea in the moment.


Best

Klaus

[kwinkler]

Upon further study (or perhaps it is a new development), the problem is not limited to LiveCode 4.5.2. It also appears with versions 4.5.1 and 4.5.3. When a new substack is opened, it runs the preOpenStack and the openStack functions of the MAIN stack. Another substack does NOT show this problem, but I can find no significant differences between the substacks. One of the substacks that shows the problem is completely empty and has no scripts associated with it. If you 'go to' the substack when it is open, it simply comes to the front. But if you 'go to' the substack when it is closed, it opens and runs the preOpenStack and openStack functions of the MAIN stack. Very strange.

[kwinkler]

The solution to this one is rather interesting.

The substack that was working correctly had its own preOpenStack function. The problem substack did NOT have its own preOpenStack function. Apparently, when a substack opens, a preOpenStack message is generated. If the substack itself does not trap the message by doing something with it, the message is passed on to the main stack. So all I had to do was add a dummy preOpenStack function to the substack. This dummy function does nothing, but it prevents the preOpenStack message from being passed along to the main stack.

The same thing holds for the openStack message.....it must be trapped by the substack or it will be passed along to the main stack.

So the problem is solved.

[deebee]

The same thing holds for the openStack message.....it must be trapped by the substack or it will be passed along to the main stack.

This behavior is actually documented somewhere, but I cant remember if it's in the user guide or a lesson.

[Klaus]

PREOPENSTACK?

You were only talking about an "openstack" handler that was executed ALTHOUGH
the substack in question had its own "openstack" handler.

[kwinkler]

Klaus,

You are correct. I did not separately evaluate the preOpenStack function and the OpenStack function. I had one substack with a preOpenStack function and another with an openStack function, so with different substacks, the problem showed up in different ways.

Ken

[Klaus]

Hi Ken,

to avoid this problem in future projects, just put any "pre/openstack" handler into
the card script of the first card of your stacks!

This way only the stack with the script in its first card will execute them!
An old but extremely valuable trick


Best

Klaus

[kray]

to avoid this problem in future projects, just put any "pre/openstack" handler into
the card script of the first card of your stacks!

This way only the stack with the script in its first card will execute them!
An old but extremely valuable trick

And if for some reason you *want* to keep the code in the stack script and not the card script, another "old but extremely valuable trick" (thanks Klaus ) is:

Code: Select all

-- Stack script:
on openStack
  if the owner of the target is me then
    -- code runs for this stack only
  else
    -- code runs for any stack that's opened other than this one
  end if
end openStack

The reason this works is that the openStack/preOpenStack/closeStack messages get sent to the *card* first, and then move along the message hierarchy to the stack itself. So since the "owner of the target" (that is, the "owner" of the card) is the stack itself, checking to see if the owner of the card is *me* (the stack whose script is executing) will filter the message accordingly.

[kwinkler]

Klaus, Ken,

Thanks for the hints. I'm sure they work, but I will have to study them for awhile to figure out why they do. I'm still learning to think in an "object-oriented" way.

Ken

[Klaus]

Hi Ken W,

no need to figure out why this happens, just read the first sentence of the last paragraph of Ken R's last posting,
where he explained it very understandably

But of course, if you want to go the hard way, just do not read it and take your time


Best

Klaus

[kwinkler]

Hi Klaus,

I'm sure that sentence is clear to you, but I think I may have to research it a bit

Ken

[Klaus]

Hi Ken W.,

sure

Then I would recommend to take a look here, which covers in detail what Ken R described in short:
http://www.fourthworld.com/embassy/arti ... _path.html


Best

Klaus