; Create database containing data from all three account-based files
openfile intermediateDbPath + "IraStats"
saveas intermediateDbPath + "AccountStats"
field 2 ; occasional 'Field 2 does not exist' message
insertfield "Account"
field Account fill "IRA"
save
let lvArray = "JointStats,RothStats"
looparray lvArray,",",fileName
openfile intermediateDbPath + fileName
field 2
insertfield "Account"
window "AccountStats"
importdatabase fileName
field 2 emptyfill fileName[1,-6]
zlog "emptyfill fileName[1,-6] completed” ; executes
save
zlog "saved AccountStats" ; never executes
endloop
runs faultlessly in High Sierra but, in Big Sur, always fails at the save command. Relocating the save statement outside the loop might fix it but I want to know why this arrangement fails.
Nobody seems either willing or able to address this issue so let me take it a little further.
Thirteen lines of code prior to the code quoted above, within a loop that’s executed six times, is an innocuous closewindow statement. Removing this statement gets rid of the problem completely. Jim has made it clear on several occasions that file closures can cause crashes and/or freezes and this latest experience appears to bear that out.
The elephant in the room is the question of why this is so. Panorama has been around for almost 35 years and suddenly, with no explanation, closing a file has become a dangerous activity. Is this a Panorama X 10.2 problem? Is it an Apple problem? Is there a solution or must we forever avoid closing files until all processing is complete? Might there be other, as yet unrevealed, problems of a similar nature? And why does nobody else seem at all concerned about this?
While many will say that it is not a threading problem, I am seeing what seems to me to be a timing issue. I had several problems where control away from Panorama and back to Panorama (ie. AppleScript) was different. As others have noted, a Wait fixes things.
In addition to whatever bugs we imagine may have crept into Panorama or Apple code don’t fail to consider bugs in our own perceptions of what our code is doing. If closewindow is in fact closing a different file than we expected something “unexpected” is apt to occur. An all too common event in my own code. Using the more specific closedatabase "A" has avoided some of them. Zlogging active window and databases has identified some more. I infer there are a few things I think I understand about Panorama which aren’t quite so. So I keep trying to learn new coding tricks, but also mine the forum for clues to whatever I need to unlearn.
I provided a detailed explanation of this 14 days ago.
But – here is an even more detailed explanation.
Panorama relies on Apple’s code for document and window management. In the pre OS X version’s of Mac OS, Apple’s code was all synchronous. For example, if Panorama’s code asked Mac OS Classic’s code to close a window, it would be guaranteed that that task would be completed before Apple’s code returned. This also applies to “Carbon” under OS X. So as far as Panorama 1-6 was concerned, all operation was synchronous. This matched up perfectly with Panorama procedure code which is always synchronous.
Appkit (i.e. OS X and macOS) is different. All document and window management code is asynchronous. When Panorama asks Appkit to save, Appkit returns right away, then performs the save later. The same for closing a window, and many other things. This doesn’t play well with Panorama’s synchronous procedure code. Fortunately, in most cases, Appkit provides a mechanism that the calling program can use to find out when a task is actually finished. So Panorama has a ton of convoluted code that requests that Appkit perform a task, then puts the procedure code on hold until it gets the word that it’s ok to proceed. Even updating the screen requires this convoluted process, which massively complicates the code required to run even simple procedures. It’s much more complicated than it was in Mac OS Classic, but it all runs behind the scenes invisible to you, though it is somewhat described.
Unfortunately, it appears that Apple thinks no one cares about when the task of closing a document or window is actually completed. They have provided no mechanism to notify the calling program that this operation is finished. Panorama may be the only program that would actually care – most programs would just ask for the item to be closed and then wait for additional mouse clicks or key presses. Who cares when the close is actually finished? But for a Panorama procedure code, it could be critical if that code is going to perform more operations based on the close task being complete. Well, Apple doesn’t care. They haven’t provided for that.
I do have an idea for a possible backdoor way that Panorama might be able to figure out when the close operation is finished. I’m not sure if it will work or not. In the meantime, yes, Panorama code should not close a database and then continue on to do other things that rely on the database actually being closed.
It’s easy enough to send a database to the background and activate a desired database. That effectively gets the first out of the way. Why not go that route, then close databases after your procedure(s) have finished running?
Jim, sorry if my question has been covered before, but on a related question. Does the same issue affect a save statement?
Sometimes I save data to a text file and then immediately try to open the file with another program. On some occasions, I get an error indicating the the file does not exist. It seems like another program is trying to open the file before the save is finished, suggesting PanX has not gotten confirmation back from the OS that the save is done. Easy enough to work around. Do you think my understanding might be correct in this situation? Could those save and saveas statements be affecting Michael’s code?
It should not. Apple does have a mechanism for notifying the calling application when a document save operation is complete, and Panorama uses that.
Sometimes I save data to a text file and then immediately try to open the file with another program.
This is a different operation than saving a document. I assume you are using either the filesave or export statement. These statements use Apple’s writeToURL:options:error: method to write the data to the file. I’ve always assumed that this method is synchronous, since there is no mention in the documentation of it being asynchrounous, nor any documented mechanism to find out when the operation is finished. I have always assumed that this was because the operation was guaranteed to be finished (in other words, that this was a synchronous method). A google search just now has not turned up any definitive information on this.
When you save “immediately try to open the file with another program”, what does that mean? Is this something you are doing manually? Or do you have Panorama code that triggers the other program?
Actually, saving a file and then opening another program to view the results is something I do ALL the time. For example when working on the Panorama documentation I will render the .html file and then immediately view it. I’ve never had a problem with that no matter how large the file is. I think that writeToURL:options:error: really is synchronous.