Scope of local variables (was Warning of problem with Print)

Panorama X Beta 10.2
1

This is something that arose, and it turns out to be something that I ran into with the pagesetup problem. That is that using these statements that bring up Apple’s Print system dialogs stops anything else from working. In my case, I was asking for information (dates) to be inserted into forms that I was printing. Previously (probably Panorama 6), I was using local variables, but I found that I needed to use file global variables when I used print “dialog” because otherwise the variable would not be found when printing.

Actually, I do not remember this problem the last time I used this, pre-Covid, so this could be a bug that has arisen since then.

2

Local variables are only accessible within the procedure they are defined in. They cannot be accessed in any other procedure, and cannot be accessed in any form, whether for viewing or printing. This is not new – it has always been the case since local variables were invented over 25 years ago. Your recollection that you previously used local variables for this must be incorrect.

3

I checked the last time I used this procedure, and it was February 2019, and if I had problems with it then, I would have fixed them then. This is a league roster, so I just duplicate and update the filename every season.

What I am doing is printing a sign-up sheet for dinners on specific dates. The procedure asks for the dates, and then prints it using the date that is input in a text display object. Now, the form comes up, showing the proper date, but Print “dialog” prints a “variable does not exist” error. Strange, and possibly from a change on Apple’s side. There is not harm in changing it to a fileglobal, but I thought I should report a change in behavior.

4

I did just think of one special situation where a local variable could be printed in a form. If you print the form with the printtopdf statement, the entire printing operation is contained within the procedure, so local variables defined within that procedure can be used on the form. I have just verified that this actually works. But personally I would not rely on this. (And of course this is not a change from Panorama 6 because in Panorama 6 there was no printtopdf statement.)

I did a bit of further testing, and it turns out that if you user print dialog the local variables work but only on the first page. Apparently the system is printing the first page while the procedure is still running, but the other pages are printed after the procedure has stopped running. I suppose it is possible that in Carbon (in other words, Panorama 6) the system might have printed the entire document in the context of the procedure. I’m not going to go back and test that now.

The bottom line is that by definition, local variables are for use within the procedure where they are defined, and nowhere else. All variables used in a form should be either fileglobal or global variables. Local variables should not ever be used in any form, and that has always been the case. A local variable only exists from the local (or let) statement until the end of the procedure, then it is gone without a trace. When the local statement creates the variable it is tethered to the running instance of the procedure. Outside of that specific procedure, the variable doesn’t exist.

5

All I can say is that it worked before, because I would have changed it if it had not. Previously it was Local instead of FileGlobal:

 FileGlobal dDate
 Gettext "Date of dinner?", dDate
 dDate=datepattern(date(dDate),"Day, Month dd, yyyy")
 OutlineLevel 0
 Field «Last Name»
 SortUp
 openForm "Dinner Roster"
 Print Dialog
6

I have made changes to the documentation to explicitly state that local variables cannot be used in a form. I thought that “only works within the procedure” was clear enough, but I guess it is better to just straight out say it.

7

Here is a little procedure on one of my forms:

Screen Shot 2022-10-31 at 3.34.47 PM

When you say that local variable should not be used on forms, are you saying that they should not be used in the “Procedure” box on the form, as my screenshot shows?

8

He means that objects on the form should not be used to set or display the content of local variables. Procedures of all kinds can declare and use their own local variables.

9

OK. Thanks for the clarification.

10

The procedure in your screenshot is fine as long as iRevise is never references or used anywhere outside of that box.

FYI, it has nothing to do with your question, but this code could be written with a single statement:

printtopdf info("desktopfolder")+
    "Kerian PO "+PO+?(emptycell("Revision"),"","R")+
    ".pdf","onerecord","true"
11

Thank you for the extra explanation; and thank you for condensing my code!