go to stack exits handler

[dunbarx]

I have a handler that navigates to a substack:

Code: Select all

dostuff
go stack "someSubStack"
doOtherStuff

The handler exits after the "go" line. There is nothing in either the card or stack script of stack "someSubStack". I have several other substacks of the main stack, and they all exhibit this behavior.

If first I navigate to "someSubStack", and then run the handler, all is fine. The fact that the target stack is not in memory seems to cause the issue. The problem, assuming I had to work such an outrageous kluge, is that I cannot even pre-open any of those stacks anywhere in the oencard or openStack routines in the mainstack, because, guess what, those handlers "quit" at that line.

I bet the answer is simple. v 8.1.8

???

Craig Newman

[MaxV]

It's a new bug.
On v. 6 the code works.
On v. 7 the code works.
On v. 8 the code doesn't works.
On v. 9 the code doesn't works.

I added the bug http://quality.livecode.com/show_bug.cgi?id=20767

[dunbarx]

Hi.

I made a new stack and a substack. In a button on the mainstack:
on mouseUp
go stack "untitled 2"
answer random(99)
end mouseUp

Works fine. There is something about my own stack/substack getup that causes this to fail.

Craig.

[jacque]

I'd suspect the handler after the "go" command, or even the go itself. What do you get if you check the result after the go command?

[dunbarx]

Jacque.

There is no handler after the "go" command. A single handler in the mainstack navigates to the substack and then continues, in-line, to do things on that subStack.

The stack and card scripts of the substack are empty.

This works fine if the subStack has already been opened, but fails if not. So in a new session, I have to run the handler, which opens the substack and then "quits", and then run it again, where it then does its thing.

This works just fine, that is, running the handler twice. This is not the way I understood life was all about.

I tried to get the result, but this fails, of course, because of the issue itself:

Code: Select all

go to the stack
answer the result

The line after the "go" never fires, because the handler has quit.

Unless the substack is already open, as I said, and in that case the result is empty, as it should be.

I know of no way to place all the substacks in memory upon initial opening of the mainstack, apart from "going" to those stacks. I could just not know how to do that of course, and that would solve my problem, though not explain my problem.

Craig

[jacque]

Substacks are always in memory, LC loads the entire stackfile at once when the mainstack opens. They aren't in the message path but they are in memory.

Do you get anything if you wrap the "go" in a "try" structure?

What do you get if you put this line before the "go" line:

answer there is a stack "someStack"

[dunbarx]

Jacque.

I misSpoke. I knew subStacks were in memory. I should have said, "never been opened before".

Now then.

If I have this:

Code: Select all

doStuff
  --try
    -- go stack "mySubStack" 
   --end try
         
  --go stack "mySubStack"
  
  doOtherStuff

If I uncomment the "go" line, I have my old issue. Two passes required to get the handler to complete.
If I instead comment the "go" line, and uncomment the "try" structure, it works first time every time. I can read the data in a catch statement if I want to, but I do not need to include it inLine.

So my problem is solved, but I don't know why.

Oh, and just leave it to you to find a dusty corner somewhere that means something important.

So is this if interest to anyone but me? Should I send my stack to the team?

Craig

[dunbarx]

The errorVariable in the catch portion of a try construction is empty if there are no errors. If I add one in my handler it reads:

Code: Select all

89,88,1
77,88,27
449,88,4
535,88,1
241,88,1,logoInitialise
353,0,0,stack "/Applications/LiveCode Community 8.1.8.app/Contents/Tools/Toolset/palettes/start center/revStartCenterBehavior.livecodescript"
573,8,1,logoInitialise
241,8,1,openStack
353,0,0,stack "/Applications/LiveCode Community 8.1.8.app/Contents/Tools/Toolset/palettes/start center/revStartCenterBehavior.livecodescript"

The fact that an error is generated, but the handler continues without issue is odd to me. Not that I am complaining. So in one case I get no error thrown, but no functionality. In the other case I can register an error, but everything works fine.

Craig

[jacque]

The error is in the LC Start Center, and since IDE errors don't report themselves to user scripts that's why you don't get a report. Apparently there is some type of initialization that fails (error 89 is "no such object".) I suspect if you close the Start Center the error will be gone, assuming it's open. Since this is a bug in the IDE, it's worth reporting.

I don't quite understand what you mean by commenting out the "go" inside the try structure. That shouldn't allow anything to happen. It's the equivalent of "try to do nothing at all". There's something strange going on if that makes a difference. The only reason I suggested a try statement was to catch the error and see what the real problem was, which is what you did.

[FourthWorld]

Good find. Moved to "Bug Triage". Please post the link to the bug report when it's filed.

[jacque]

I don't quite understand what you mean by commenting out the "go" inside the try structure. That shouldn't allow anything to happen. It's the equivalent of "try to do nothing at all".

Oh wait. I think you mean that this works:

Code: Select all

try
  go stack "mySubStack" 
end try

But this doesn't:

Code: Select all

go stack "mySubStack" 

Right? That would make more sense.

[dunbarx]

@Jacque,

Start center is not open. Never use it. But is it in the message path? Otherwise, how do it know?

@ Richard.

I did report it, and told them to read the thread, which has now moved. I will update at QCC, because I think the history of this is worth it, and hard to enunciate in the report form there.

But don't you think this merits staying in the mainline panes of the forum? I bet most users do not read the stuff in "bug triage"

Craig

[dunbarx]

Right? That would make more sense.

Correct.

I actually did not say "commenting out the go inside the try structure.."

Craig

[FourthWorld]

I did report it, and told them to read the thread, which has now moved. I will update at QCC, because I think the history of this is worth it, and hard to enunciate in the report form there.

Yes, I went back through the posts to find the report link. Thanks for including that, and for keeping it up to date.

I don't understand the "enunciate" part, but if it's easier to paste a link than to paste the recipe, if they don't mind I certainly don't.

But don't you think this merits staying in the mainline panes of the forum? I bet most users do not read the stuff in "bug triage"

There are dozens of sections in these forums. What defines "mainline"?

We all have our favorite topics. I'm not sure I want to suggest we put a thread in whatever section will get the most views, as opposed to putting it where it seems most relevant.

"Complete Beginners" is for complete beginners to ask questions about getting started learning LiveCode.

"Bug Triage" is for honing recipes for bugs before filing a bug report with that recipe.

Seems you found a bug, some exploration yielded a good recipe, and a bug report has been created.

Unless there's something about this that isn't bug triage, Bug Triage seems a good fit,

Besides, with so many sections here most regulars use the "New Posts" link.

[dunbarx]

Richard,

OK.

Bug # 20770.

But there is a deeper, or at least more sinister issue. The recipe is peculiar to a particular project of mine. A new stack/substack combo does not exhibit the behavior. I do not need a "try" gadget to be able to navigate to another stack and have the controlling handler keep on working.

Craig