Good news. I just upgraded to macOS 10.12.4 (released today, 3/27/17) and it fixed the consistent crashing of Panorama X. Whenever I had 2 files open, it would always crash on quit, and sometimes crash with only one file open upon quitting.
I’m happy to report that since installing this latest upgrade a few hours ago, I cannot get Panorama to crash at all. I first upgraded my laptop and checked. I was so happy with the result, I upgraded my iMac as well. All seems good for now on both machines. 27" late 2013 iMac 3.5 GHz i7 and a 15" 2011 Mac Book Pro 2.5GHz i7
I did not have many crashes before, but I can confirm: Panorama X acts faster under macOS 10.12.4. I see no beachballs anymore, when I quit Panorama X or when I close files. It seems to run with less friction.
Good news, thanks!
I lately had frequent crashes when I made changes in a functioning database, I don’t know what triggered it but suddenly the file couldn’t be saved any more because «it didn’t exist». Force quit, restart, make one change and the same hassle all over again.
The only way to get out of this was to duplicate the file in the finder and continue work on the copy.
Hope, this will stop now!
I have a simple database that crashed whenever I closed it, and now that seems to have stopped. There have been so many of these crashes that I have been reluctant to work with Panorama X. I guess I can start working with it seriously now.
If true, that is really excellent news. As you may know, for the past four weeks or so Panorama has been collecting stack traces whenever there is a crash and sending them to me. That has allowed me to see that there is one crash that is by far the most common, about 1/3rd of all Panorama X crashes. Unfortunately, I haven’t been able to make any progress on this particular crash, and the stack trace shows that there is no Panorama code running at the time of the crash, only Apple code. Mark, I checked to see what the crashes were that your computer has been reporting, and every single one of them is this mysterious crash. So if this really has been an Apple bug that is now fixed, I would be very happy about that. I will be watching very closely to see if this crash ever occurs with 10.12.4, or if it is really solved for good.
I sent you an email about this over the weekend, I think maybe you didn’t receive it. Based on the crash reports that came in from your computer, I was able to find and fix this problem. Panorama X was crashing on data entry if the Input Range has an odd number of characters. So if the Input Range was something like this:
AZaz0
It would crash as soon as you hit a key in this field. For now, you can fix this by changing the Input Range to:
AZaz
or
AZaz09
or anything with an even number of characters. Other than András only one user has been affected by this recently, William Markham. So the two of you need to check your Input Ranges.
Jim, I did receive this mail, thanks. However, by pure coincidence just a few days prior to this I scrapped the input formatting from the field in those databases but the inability to save because “the file doesn’t exist” continued. It might have been due to old forms from Pano 6 converted to Pano X which still linger in the background. I started to scrap those too, because they are useless in Pano X. I have to make them again there to be useful.
Anyway, I have Sierra 10.4 now and should the crashes stop from now on, I’ll never know if they were due to an Apple bug or some incompatibility within Pano 6 - Pano X.
I had a crash last night on 10.12.4 from opening the sheet on a database that was exhibiting other problems. I could finally get it to open when there was a sheet from a blank database that was already open.