When using callwithin, variables required by the subroutine addressed must be declared in the subroutine itself. If they are declared in the procedure before the subroutine they are ignored as the callwithin statement jumps straight to the subroutine.
I can’t find any reference to this limitation in the forum or in the help documentation, where I think it would be helpful.
In this respect callwithin is not exactly a combination of call and shortcall statements as stated in help, as this limitation does not apply to them.
In Panorama, variables are declared dynamically, when the procedure runs, not when it is compiled. The statement that declares the variable must actually be executed in order for the variable to be declared. If you bypass the statement, it isn’t executed. That’s going to happen no matter how you bypass it, whether you do it with an if statement, a case statement, a shortcall, a goto, or callwithin.
True. I usually declare variables at the very start of procedures, so I was not expecting them to be ignored. I do see the reason, but as I mentioned it does not happen when using the call statement.
As you can see, the let statements are skipped, just as before. If you think about it, it would be a horrible bug if these statements were not skipped. The calling program requested to jump directly to the Blue label. Panorama would have no business running any code before that label.
Basically, the callwithin statement provides a way to put multiple subroutines in one editing window. This can be convenient because it reduces clutter in the View menu. But the subroutines are completely separate (unless you code in a connection, for example with a shortcall statement or a goto).
I think the documentation is correct, callwithin is exactly a combination of call and shortcall.
I hope it’s not splitting hairs to point out that this is only true when the shortcall is the first statement in the called procedure as in your example.
But the subroutines are completely separate (unless you code in a connection, for example with a shortcall statement or a goto ).
Exactly, the subroutines have to be self contained, almost as if they were separate procedures.
Basically, the callwithin statement provides a way to put multiple subroutines in one editing window. This can be convenient because it reduces clutter in the View menu.
It’s simpler than using a call statement with parameter and case statements in the called procedure which I did previously. It is such a cool tool that I use it often (probably to the point of overusing it).
It was intended that they be self contained. As far as I am concerned, that is a feature.
Virtually all programming languages allow multiple self contained subroutines in a single source file. Panorama was kind of unique in not allowing that. Now it’s caught up with the pack.
It’s also MUCH faster. Using shortcall, Panorama will jump directly to the specified location. Using case statements, Panorama has to evaluate each conditional formula until it gets to the correct spot (if there is one). Each formula takes a bit of time. Not a lot, but it can add up, especially if used in a loop.
Also, I would suggest that you should never write new code with case statements. Use if/elseif/endif instead. This allows you to nest, if needed, which isn’t possible with case statements.
I have converted most of the case statements used in my old Panorama 6 files in Panorama X.
However case statements can still be useful in procedures containing a lot of nested if/elseif/endif statements when they are used at the top nest level, to make it easier to follow what’s going on (as opposed to relying entirely on indenting). In this instance case’s inability to nest becomes a benefit.
