There has been lots of discussion about the hazards of upgrading to OS Sierra using Pan 6, but lately I haven’t seen much. Is it pretty certain now that the current public release of Sierra is fully compatible with Pan 6? Whether you upgrade the OS in a current Pan 6 system, or try to install it fresh on a Sierra system?
Will my Pan X run more reliably on Sierra?
I have completed a clean install of Panorama 6 on the latest version of the OS without any problem.
Robert Ameeti
there was a build of 12.2.1 that made pan6 run very erratically for me.
current version is ok.
I have not experienced any problems using Pan 6 on MacOS 10.12.2.
Using Sierra 10.12.3 most of my Pan6 databases have problems displaying summary Levels making basic spreadsheets unusable. Reverting to a Mac with Yosemite these same databases display correctly, so they are not corrupted.
Likewise my system-wide date preferences are for dd/mm/yy in Sierra. Even after putting this same formula in the Date Output Pattern of the Design Sheet of Pan6, the dates insist on a US entry format (mm/dd/yy). Extremely annoying.
Has anyone else seen these problems? (This is on at the latest 15" MacBook Pro with Touch Bar)
I just made a quick test and cannot confirm issues with summaries in Pan 6 under macOS 10.12.3.
Are you sure you are using the most recent version of Pan 6 (Build 121629 (Nov 16, 2013))?
I assume that your date format is set correctly in the Languages and Regions section of the Date and Time system preferences.
I experienced this date format problem back in 2015 using 10.10.4 on a brand new iMac in Australia. Others on QNA using the same equipment and/or OS were unable to reproduce the problem, taking into account that there may not have been many of us on QNA using the non-US date format in Pan 6. After spending untold hours trying to get to the bottom of it, I gave up and disposed of the iMac, and in the meantime have stuck with existing hardware until I can convert everything to Panorama X.
In the end I concluded that the cause of the problem seemed to be the actual specific iMac rather than the OS or even Pan 6, but I have absolutely no clue as to why. If you manage to solve this problem, please let me know.
David Duncan
Thank you for your replies.
I have found the problem I had with displaying the Summary Levels. I had forgotten that I used some fonts which I had placed in the Fonts folder of the User, as opposed to System Fonts. For some reason these were not automatically migrated when I transferred my Yosemite files to Sierra. So this is NOT a Pan6 problem.
However, the date format problem most definitely is. I wrote to Jim Rea and he responded, as always, very quickly as follows:
Me: Do you have any bright ideas, please, how to force the date format I want?
Jim: Sorry, no, I don’t. It will work in Panorama X, though, and you shouldn’t even have to set the output pattern.
Me: Sierra doesn’t appear to have this problem with any other app.
Jim: At this point, Panorama 6 is probably the only application you have that still uses the old Carbon API’s (the API’s brought over from Mac OS 9).
SO, Jim is suggesting that changes made by Apple in Sierra account for the non-US date problem. No fix in sight.
I suppose the only workaround is to laboriously go through every database and change the dates manually to Text and enter them all again one by one. Not really an answer when you have over 100 databases going back to the OverVUE days!
David
If you want to send me a sample file (make sure you compress it first), I’ll see if I can come up with an automated method of rewriting your data. I’m in Australia, so I’m also using non-US date formats. I’m not on Sierra but that isn’t a problem if all you want to do is reformat the data.
michael
audax@wideband.net.au
A FormulaFill in a text field with a formula like
datepattern(Date, "dd/mm/yy")
should transfer those dates to the text field in the desired format. Replace Date with the actual name of your date field. It shouldn’t be necessary to type those dates one by one.
Dave and Michael
Thank you both for these posts. I missed them when you posted them and only now came across them both.
As Jim commented not long ago in another thread, the only real problem with the non-functioning non-US date format is with the date( function. I am coding for some computers which convert date( one way and some computers which convert it the other way, so here’s my solution to test and then adapt when necessary:
If date("06/03/17")=2457819 //how does 6 March 2017 convert?
lDate=date(lDate)
Else
lDate=date(array(lDate,2,"/")+"/"+array(lDate,1,"/")+"/"+array(lDate,3,"/"))
Endif
The date chosen does not provoke an illegal date error when processed by the US date format computers, but converts to Panorama’s June 3rd number, which fails the test.
The real problem I faced was that each time I use date( the date format being processed may be different, so I had to examine each circumstance to be sure the fix after the Else statement worked. I guess I have used date( 70 or 80 times across my P6 files, so it’s been quite a bit of work.
David Duncan