|
Post by Jerry Muelver on Oct 16, 2007 13:39:56 GMT -5
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.
|
|
|
Post by carlgundel on Oct 16, 2007 14:20:44 GMT -5
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
|
|
|
Post by Brent on Oct 16, 2007 14:53:03 GMT -5
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).
|
|
|
Post by Jerry Muelver on Oct 16, 2007 16:30:30 GMT -5
You can't stop a currently running action on the server by clicking on a link. Is that what you're trying to do? 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.
|
|
|
Post by carlgundel on Oct 16, 2007 16:35:49 GMT -5
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? 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
|
|
|
Post by Jerry Muelver on Oct 16, 2007 16:54:16 GMT -5
|
|
|
Post by billw on Oct 16, 2007 17:14:17 GMT -5
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!)
|
|
|
Post by Jerry Muelver on Oct 16, 2007 18:10:25 GMT -5
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.
|
|