Jump to mainline branch from sub

It would be really convenient for me to be able to jump from a SUB to a branch in the script root, for instance to go from a link sub to the program's mainloop branch label. Then I would have a "Restart" kind of link, so my user could abandon the current display file processing and open a new file. I know I can do that by using a branch label for the link handler, but then each I lose the ability to process dynamically-named (input file-created) links.

You can't stop a currently running action on the server by clicking on a link. Is that what you're trying to do?

As for being able to branch out of SUB to a label in an outer scope, that would mean the SUB knows more about its outer scope than it should know.

-Carl

Jerry, you specify an ON ERROR branch and then inside the SUB generate an error. It's unfortunate that RB/LB don't support the ERROR statement for explicit error generation (kind of like "throw" in structured exception handling).

Nope. I just want to offer the user a choice clicking on a link on the displayed generated page to continue reading the "book", or click on a menubar link to quit or to load a different file.


Yup, I agree. I didn't say it was possible, or even a good practice -- just that it would be convenient for me, personally. ;)

If I have a link in a sub, and use a branch to handle the link action, doesn't the branch have to be within the sub? It looks more and more like I have to rebuild my project with more branches and fewer subs. It's a little more mental bookkeeping to program that way, but it would seem to resolve some of the obstacles I bump into these days.

Brent -- catching a deliberate error is an interesting option, and something I might want to use for certain file-accessing widget behaviors, but that would really still need a TRY or RESUME action to rise above the level of a kludge. ::)

Well, no. A yet to be documented aspect of WAIT in RB is that when used in a sub it causes the current process to be terminated and renders the page. Any events after this will be served by the top level scope.

-Carl

:o :o :o

That explains some of the suspicious behavior my programs exhibit when I (mis)use WAIT. ::)

Quite simply, I just didn't know what I was doing, which is a condition that surprises me these days in both its frequency and its depth. Oh well, it's time to kick in Muelver's First Law of Programming -- As soon as you get your prototype proof-of-concept working, throw everything away and start over from scratch, to capitalize on the lessons you've just learned.

Carl: You're saying that WAIT kicks execution back out to the top-level scope? Will that also be true in LB5? That'd break a lot of LB code... Not the least of which is Freeform. Is it just me, or will Freeform need to be completely re-written?

But enough about LB...

Jerry: I didn't know that was a law. ::)

For your problem, consider the design of dbman. There's a link handler sub that, when called, resets the DB connection and calls up my main menu. The main menu is in another sub, with only some GLOBAL declarations in the top-level scope.

(let's see if I've got this right after five edits!)

Thanks, Bill. I'll do some serious playing with DBMan later tonight. I think it addresses the same circumstances I'm working on -- buncha text gets parsed, processed, and reformatted, then rendered as a page, then the user picks an option from a template-like (global) menu or chooses from some dynamically-generated links on the rendered page, then we go again. I have to think more asynchronously than the "constant flow of info" architecture I've been using. ::)