Lock messages question

[dunbarx]

I have a button that navigates to another stack:

Code: Select all

...
go stack "shapes"
...

The code right after that line does lots of stuff in the stack "shapes". But the handler ends right at that line. Now if I click on the button again, the entire process proceeds normally. I assume since the stack "shapes" is already open and in memory all is well.

But if I do this:

Code: Select all

...
lock messages
go stack "shapes"
unlock messages
...

the process proceeds as advertised.

The stack "shapes" has its "purge" options unchecked, and its "destroyStack" is "false".

Both workarounds, either clicking the button twice or locking and unlocking messages fix this just fine.

So what gives?

Craig

[RCozens]

Hi Craig,

Does the stack or card you are in originally include a closeStack or closeCard handler?

Turn on the Message Watcher and see what message appears after the "go stack" statement.

Another option: if you are running a handler in stack "shapes" and then returning to the original stack, you could run the handler without going to it.

Code: Select all

 send "handlerName" to stack "shapes"

Rob

[stam]

I was going to ask the opposite... does stack "shapes" have a preOpenStack, openStack, preOpenCard or openCard handler?

If calling something before the stack has 'opened' properly code can fail if it is referring to interface elements in the destination that haven't yet initialised, and it may be something like that happening - code failing in the destination stack and halting execution but once the destination stack as loaded properly it then works as expected on subsequent runs.

You may want to pass the code that 'does lots of stuff in stack "shapes" ' to the actual stack shapes by creating a new handler in the destination stack to which you can pass the variables you're presumably creating in the source stack; this new handler would then cascade through all the code you were running from the source stack.

Maybe wrap the calling code in a try/catch block and check the result to look for specific errors?

if on the other hand you're just using the destination to run a function or handler, may use 'start using stack "shapes" ' instead and then you can just use its functions/handlers without navigating to it.

Difficult to suggest anything more concrete without knowing much more detail!
HTH
Stam

[richmond62]

Tangentially, although my Devawriter Pro source stack keeps opening the message box, perhaps obviously, that does NOT happen in the standalones, so I really wonder if it is worth bothering about.

[dunbarx]

Thank you both for the replies.

I understand how such "open-type" handlers might interfere with a local process, but commenting them out never changed anything .

The "Shapes" stack is a single card, and does indeed have an "openCard" handler. But there are only two lines in that handler, and both only do some bookkeeping once on the stack.

So it turns out, after years of having to kludge my way through this, that as of today, the stack opens normally, "openCard" handler in place, and a single "go" command just does its thing. I tried it with earlier versions, and they now all work as well.

It is almost as if fooling around with the code somehow fixes it. And I know that operator error is invariably the real issue. But in earlier versions that I have not touched for weeks???

I will never understand how these things work.

Craig

[dunbarx]

Stam.

You may want to pass the code that 'does lots of stuff in stack "shapes" ' to the actual stack shapes...

Always a sound idea. I built this stuff gradually, and just never tightened it up.

Craig

[richmond62]

I built this stuff gradually

Sounds like every piece of software I ever developed.

You get a big, wet, sloppy kiss from me for that remark that hits most of my problems right on the button.