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.
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.
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.
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.
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.