A new Panorama X release is now available. Most users can simply let Panorama automatically update. If you have any problems with the automatic update, the direct download link is:
Or, you can simply go to http://www.provue.com and download the trial version, which is the same version.
This version fixes the known problems with macOS 15 Sequoia, as well as problems introduced with the b40 version. It also includes the changes listed below.
Fixed b40 problem with pop-up menus messing up the key window (this affected various dialog, for example Find/Select).
Fixed various File>New>Database commands that were broken in b40.
Panorama now gives you the ability to easily recompile all code and formulas in a database, see the Recompiling Code help page. Recompiling is mandatory for existing databases if they use any of these functions - after(, before(, tagstrip(, xtagvalue(, tagdata(, tagcount(, rawtags(, tagstrip(, striphtmltags(, tagstart(, tagend(, replacefirst(, regexreplacefirst(, regexreplacefirstexact(, jsonscriptstring(, imageinfo(, htmltablecellraw(, htmltablecell(, htmltablerowraw(, htmltablerow(, htmltablecellexists(, htmltableheight(, htmltablewidth(, panoramaservercgisuffix(, panoramaxserverurl(, localpanoramaxservername(.
New SaveAndClose statement saves and then closes a specified database. This is recommended instead of using separate save and closefile statements.
A procedure can now open a database with a filename that contains a period. For example opendatabase "example.mailing.list" will now work.
The importtext statement has a new fieldtype option that allows any new fields created during the import as integer or float types (instead of text, the default).
Fixed the setfieldproperties align option. In the past center/right were reversed, and it would only work for capitalized words. Now center, Center, and CENTER all work correctly, also right, Right, and RIGHT.
The Make New Database with Crosstab Data command (Crosstab Workshop) now has greatly improved performance when exporting crosstabs with large numbers of rows and/or columns.
New Unlock Window Order When Running Code option in Advanced Preference panel. When this option is enabled, the user will be able click on background windows and bring them forward - even when a procedure is running. Hopefully this option is never needed.
Fixed the scope parameter of the WAIT statement - previously it always used database scope no matter what was specified.
Documentation corrections from David Scott, James Cook.
B41 version notes arenāt listed within its Help.
SaveAndClose is listed and appropriately crosslinked in its Help, BUT it doesnāt show in topic list nor via even full text searches. Am glad it was linked as I anticipate updating a lot of code with it.
Ok, I see I can access the B41 version notes via the Check for Updatesā¦ menu, but Iād expected the current version notes to also be within Help.
The Recompiling Code Help page is also not available via the topic list or search, although I could reach it via links at the Code Help page. The associated statements for doing that programmatically were listed in topics and searchable.
Just thought of a potentially significant question. Due to some procedures unexpectedly quitting PanX with B40 Iāve been running them under B39, but otherwise running those dbs with B40. I hope B41ās āfixes for what B40 brokeā turns out to fix that. However, if some of those dbs need recompiling for B41 then I suspect they would no longer run on B39.
Iāve tried to ābackupā my dbsā procedures as one or two text files per db in one folder whose files I can search at once with BBEdit. If that ābackupā is correct the known B40 troublesome dbs donāt include any of the listed functions. So perhaps I can still bounce between B41 and B39 if necessary. However, they do include textbefore(. Should that, like before(, also be on the list?
I did identify a different db, with no known B40 issues, that needed recompiling for B41. That was easily doneā¦ once I found the Help page.
The Recompiling Code help page does not contain or refer to the list of functions for which recompiling is said to be required in the b41 release notes. The help page does say
there is [only] one exceptional case where you may need to manually force code/formulas to recompile
but this seems unrelated the list of functions in the b41 release notes.
So why is that list of functions in the release notes?
I interpret that as this being the first version change to ever change how Panorama internally compiled raw code. Prior to it, code compiled in earlier versions would continue to work in new ones. The functions listed wonāt work in B41 without recompile, those not listed still would work without it.
No harm in recompiling, unless as I guess, you are using functions on that list and wish to revert to an earlier version. In which case the B41 compile of them wouldnāt work. If you are fine with B41 and want to recompile everything at once, create a finder smart folder, with search criteria to include every PanX database. Then select and drag all its contents into the recompile token on the preference pane.
Actually, the functions listed wonāt work on Sequoia without recompile. They will still work in in previous versions of macOS. But I would suggest taking care of it now if you use any of these functions. Once recompiled, they will work on any version of macOS. And the recompile step is very fast.
I think they would still run. But if you ever edited them in b39, you would need to recompile them again using b41 (or later) or they wonāt work on Sequoia (or later, unless Apple fixes the problem, which I suspect they never will). See my comments below about bouncing between versions.
Nope. The textbefore( function does not need recompilation.
I hope so too. If it doesnāt, let me know, there is a further step available in b41. But I donāt want to use it unless necessary.
You may already know this, but bouncing between Panorama versions has been the source of various problems over the years. Sometimes the problems turn out to be worse than whatever the person was trying to avoid by using multiple versions. Whenever possible, I recommend always increasing the version number, and never decreasing.
Have you ever looked at Panoramaās blueprint feature? Itās designed to do exactly what you are trying to do. I use it to track database changes in git, but you can also use it for BBEdit searches.
I always check this after building a new release. Itās right there on the Release Notes page.
Ok, somehow this, and the new Recompiling Code and SaveAndClose statements did not get into the search. Thatās a new type of failure, not sure how that happened. Here are the links for the 4 new pages. Iām not going to make a new build just for this, but Iāll make sure this is resolved in the next version.
Thanks for the fixes to which you discovered B40 broke. Iāll test them in a couple days.
Smart folders are a good trick, available āin the box,ā whenever you need to do batch operations on many randomly located files. If you can construct a Spotlight search, finding all of and just them, you can reuse it like a Find/Select Favorite. If desired you can add Finder tags, which Spotlight can see, to show whether youāve yet done āwhateverā on given files in the batch and create additional smart folders for just those tagged files.
If you select all of a smart folder contents and drag them into a Procedure Window you create a text listing of all their paths. PanX has great tools to search which open dbs have āsomethingā you want to change, but canāt directly parse closed ones. From that listing you could loop through and open briefly otherwise closed dbs to be searched, and generate a sublist that had āsomething.ā
I started saving db Procedures to text files prior to PanX and Blueprints being available then wrote comparable PanX code to continue my practice. If I were starting from scratch, knowing what I know now, Iād probably save Blueprints instead, but Iām used to my status quo. Theyād have the biggest scope so potentially BBEdit searches could find more than my current approach. On the other hand the bigger scope could return hits I didnāt want, which current approach would skip. Iāll probably append code saving db Blueprints to a different folder to my present procedures. After which I could pick which folder, and thus scope, to search via BBEdit. Then I need to start searching my code for places to swap in SaveAndClose statements as a fair chunk of the error messages I get point to the problem itās designed to fix!
As a feature suggestion I donāt see any syntext for programatically invoking saved Favorites in Find/Select or other dialogs which offer Favorites and programatic equivalents. You can certainly recreate the equivalent in code, but the ability to utilize a manually saved Favorite, could be convenient.
When I try to recompile any database I am getting a āField or variable _DisableServerConnections does not existā message. I do not use PanX server. Have tried multiple dbās using either drag/drop or the choose file dialog, all with same result. I do observe with some chagrin that no one else is reporting this. Anyone have an idea what could be going on? [Mac OS 13.7 Ventura; PanX 10.2.0.b41]
Iām also kind of concerned that no one else has reported this - I think it may mean that no one else has actually tried to recompile.
Iāve fixed this for the next release, in the meantime, you should be able to get it to work by switching over to the Client panel and toggling Disable server connections on and off again.
The workaround in the Client tab of the preferences works.
But there is another issue: The Drop procedure in the Pan X preferences window refuses to run when there are duplicate file names.
Another problem of that Saved Search approach: It works with many selected databases, and it is very fast ā as long as there are no recompile errors. When there are errors (in my test with 8 selected databases containing known compilation errors), I am getting a summary dialog saying āRecompiled Databasesā, but NO error report.
Iāve encountered it several times but hadnāt gone through all the steps I would ordinarily take before reporting it. I first suspected it had to do with shared files, except that it then managed to handle some shared files.
Moments ago while recompiling a set of files, I had to Force Quit when the progress bar stayed on the window. Iām guessing the files were recompiled, but is there a way to tell?
I also ran into the duplicate file names issue that Kurt reported. It would be nice if that could be fixed. Iāve got lots of them and using the Smart Folder would have been an easy way to recompile all of my databases.
Thatās correct. Initially you were only going to be able to recompile one database at a time. So this is a big improvement over that but you still canāt necessarily do your entire drive at one go - just one folder at a time.
This is intended for recompiling working code, not as a debugging tool.
This tool doesnāt just recompile procedures - it also recompiles every form object in every form, and also all automatic code and all automatic formulas for every field. To come up with some method of reporting errors for all of these situations would probably have taken 5 times as long to implement. Due to the problems with the b40 version I felt like it was already taking far too long to ship this update.
Possibly error reporting could be added to this in a future version, but since this isnāt intended to be a debugging tool, Iām not sure it is worth the investment.
This is using the View Organizer? This is intended as a tool for helping convert procedures from Panorama 6 to X, so it does report errors. This tool only compiles procedure code - it does NOT compile form objects or automatic code & formulas in fields.
Not really. But yeah, considering the progress bar got all the way to the end, they probably did.
No, I used my own test database with a Drag Receiver area using the recompile statement. Then I am getting those debug error reports (corresponding to the red/white warnings in the View menu).
The recompile statement only recompiles procedures. It does not recompile code and formulas in form objects, and also does not recompile automatic code and formulas associated with database fields. If you want to do that yourself in code, there is a new undocumented option built into the setdatabaseoptions statement.
setdatabaseoptions "database name","recompile",""
But as you have already noticed, this method does not report any errors.
This statement is working very fast looping through my test database, where I have used filecatalog to collect the paths of about 450 databases in my Panorama X data folder (and subfolders).
But while it works as expected recompiling and resaving all those databases, it seems to do some kind of damage to those modified files: I am not able to open any of them after the recompilation. ā Thanks God I was able to recover all the databases from my Timemachine backup.
Dragging databases to the Drag Receiver area in Panorama X > Preferences > Advanced seems to be a much safer way for Recompiling.
Looping through my test database using the recompile statement on the other hand displays debug errors for 45 of my databases ā so I can complete the migration to Panorama X where I had not finished it until now.
How do you know it works as expected if you are not able to open any of them?
When you say that you are not able to open any of them, what do you mean? Is there an error? A crash? Did it open but with no windows?
But dragging database to the preferences window uses the setdatabaseoptions statement - itās exactly the same! Though of course I donāt know what other code you are using to open, save and close the databases.
One thing I figured out earlier this week is that using the save statement on a database with no windows open causes Panorama to forget what windows were open. So the next time you open the database, it will open to the data sheet instead of to the saved configuration. The recompilation code associated with the preference window will open each file secretly, recompile, then save and close, so this means it also removes the saved window configuration. This was what caused a problem with the Dialog Workshop wizard. I have fixed this problem, the fixed version will be available soon.
All those databases were saved with a new modification date.
This was the code of my loop:
firstrecord
loop
opensecret Path
setdatabaseoptions DB,"recompile",""
downrecord
until info("eof")
I was not able to open any of those modified databases, neither via the File menu nor with a doubleclick in the Finder. I closed and restarted Panorama X to make sure the files were not still secretly open in memory. But no, they did not open.
Youāre not doing anything to save or close these databases.
If you have two databases with the same name, only the first one will be opened. Any further ones will not be touched. Panorama cannot simultaneously open two databases with the same name, even if they are in different folders. When you try to open a second database with the same name, it will simply use the database that is already open in memory.
You keep saying the databases do not open. Are they simply ignored? If thatās the case, I would be interested in getting a copy of one of these files to see what happens under the Xcode debugger.
