LC can drive you nuts

[dunbarx]

Richard.

As I said I have a simple test stack that works the way I would expect it to. Therefore of no value at all.

I have no problem sending you the project I am working on. I can instruct how to demonstrate the problem, which is simple and straightforward, but I would not wish trying to dig into the guts of the thing on anyone.

Assuming it is not some edge case bug in LC, I do not know if my issue is of general interest to anyone but me, Currently I pre-open the substack but keep it hidden until the handler that is actually intended to open it runs. I mentioned that the fact the subStack is already open allows the mainStack process to proceed normally.

If anything, that workaround makes me think it is not something I did, but rather something in LC itself.

I do not really have confidence in that last statement. Anyway, what to do?

Craig

[mwieder]

Craig-

Is "stack" your mainstack or one of the substacks?
And what substack is that closeStackRequest handler in?

[sturgis]

I've run into similar in the past. At the time, it seemed to me that a script managed to get into a "thinks its compiled, but its really not" state. I seem to recall having a recipe to make it happen, but its been a while, and i'm foggy enough to be almost useless anymore. However. If it happens again, go into the offending script. Change SOMETHING. Almost anything, as long as it turns on the dirty bit. Compile, and test. I think it may be the same issue since commenting stuff out (the "SOMETHING" part) makes it work, then changing it back, compile, it continues to work.

Hi all. Yes, I still exist. Hope everyone is doing well.

[mwieder]

Hey! Good to see you here again.

[sturgis]

Hey Mark. Good to dip the toes in the lc pool again. Things have been a bit on the difficult side of life, so I'm here to seek distraction. How are you? And your better half? (ok so maybe this isn't the place, but it is truly great to be able to say hi to good people)

[SparkOut]

Welcome back!

[dunbarx]

Mark.

- A mainStack button handler does some stuff, navigates to the subStack with a "go" command, then does more stuff.

- The destination subStack contains the "closeStackRequest" handler in its stack script.

- The simple existence of the "closeStackRequest" handler halts the mainStack handler at the "go" command. Commenting it out allows the mainStack handler to finish.

The "closeStackRequest" handler never fires. How does the subStack know it is there at all? I assume that the act of moving from one stack to the other is the critical change in the overall set-up. This is something that normally has to be considered, since the topStack has changed. I just do not know how the presence of a handler in the target subStack, that never comes into play, stops execution of the mainStack handler.

Craig

[jacque]

CloseStackRequest prevents the stack from closing unless the message is passed. I don't know why this would prevent another handler from completing but it may be that it operates by exiting to top. An experiment would be to pass the message at the end of the CloseStackRequest handler.

That doesn't explain why it interferes in the first place though.

[dunbarx]

Jacque

Thanks, but I tried that.

Craig

[FourthWorld]

Does your script "go" in the same window?

[mwieder]

Craig-

If there is an error anywhere in your substack script then it will be uncompiled. And your breakpoint will therefore never be triggered.
In your script editor Options, do you have "Live Errors" checked?

[jacque]

What does "live errors" do? I can't find any documentation about it. I turned it on anyway.

[mwieder]

I don't know if there is any documentation on it.
I unchecked it and found that it didn't flag errors in my typing.
After checking it the x in the little red circle caught errors as I typed and the Errors tab showed the error text.
Most importantly, though, with it unchecked I could Apply the script even with unseen errors.

[dunbarx]

All.

Interesting takes, thanks. But remember that if the subStack is already open, I have no issues at all. In fact, I never would have known there was a problem. It cannot be a hidden uncompiled handler; such a thing does not fix itself by virtue of being opened in a different handler than the one that fails.

The mainStack handler quits right after the "go" line. A breakpoint right after that one never fires.

That is my workaround; I always open the subStack early, whether or not I will ever particularly need it. Then all is well. It used to be that all was well regardless, but a while ago it began just not to be.

Craig

[dunbarx]

Richard.

The subStack opens in its own window, placed right next to the mainStack.

Craig