Panorama X 10.2.0 b27 Build 4102 Release Notes

admin · August 15, 2022, 8:16pm

A new public beta version is now available. If you’ve already installed b18 or later, you can simply choose Panorama>Check for Updates to install this update. If Panorama isn’t currently running, it will automatically offer to download b27 when you launch PanoramaX. If you haven’t installed b18 yet (or if you are still running 10.1), you can simply go to www.provue.com and download it.

The new b27 version includes numerous bug fixes and a handful of new features. For Panorama Server users, there is a new option to monitor and automatically relaunch if the server stops running for some reason. There is also a new diagnostic tool to double check that synchronization is working, and a new option for web only databases, which allows rapid bulk data modification to a web published database on the server.

For standalone Panorama users, Panorama now has the ability to play sounds in the background. The techniques for creating and modifying custom statements and custom functions is now documented, and slightly improved. There is also a significant change in how code is run after a field has been edited. Hopefully you won’t notice this change, other than possibly you may find that mysterious weird behavior has now disappeared. In related news, the new showlater statement will in most cases be an easier to use method for eliminating extra display than the noshow and endnoshow statements. There’s no reason to rewrite existing code with these statements, but for new code, showlater is probably easier.

New Auto Relaunch option in server preferences. This option monitors the server and automatically relaunches it if it crashes or stops responding.

image2424×1672 653 KB
Allow Panorama to ask for permission to control other apps using AppleScript (this was a new bug in b26).
Added new Check Synchronization command to the pop-up sharing menu. This is a diagnostic tool that can be used to double check that the most recent database sync worked correctly. There is also an option to do this automatically after every synchronization.

image2424×1974 523 KB
Added a suite of statements and functions to allow Panorama to play sounds asynchronously. You can now build your own iTunes or podcast player in Panorama X!

image2424×1668 342 KB
Function-Up Arrow/Down arrow no longer cycle thru cell values if the text editor has a scroll bar. If there is a scroll bar, these keys are interpreted as page-up/page-down.
Image Display colors and gradients now work again in View-As-List forms.
New DeleteObject statement, deletes a single object from the current form.
New server feature – the “No Synchronization (Web Only)” database option. This option allows a web published database to perform the kinds of wholesale data changes that can be made in a single user database, but losing the ability to synch up the database with Panorama clients.

Fixed problem between tabbing in a form and automatic code. When tabbing from field to field, Panorama now makes sure that any automatic code has finished running before starting editing of the next text editor object. (In the past, if the code did multiple assignments (or any display of data), the code following the assignment or display would run after the editing had already started, possibly causing incorrect operation.)
Added the showlater statement to defer display of database changes until procedure code is finished. This is also done automatically for certain implicitly triggered procedures, which was how the fix above this was acheived.

Fixed display of non-colored Action menu items when using Dark mode. (If the menu color is pure black, it is assumed to be non-colored, and will be displayed using the system default color. If you want it to always be black, you must use 000001 instead of 000000.)
New .InitializeHotKeys procedure in custom libraries.
Custom statements and functions are now documented.

New View Organizer menu commands to reveal the custom library folder in the Finder.
The Lock Record menu command now displays the correct alert if the record can’t be locked. (This used to display the standard error alert or open the Error Wizard, but this situation isn’t really an error.)
Fixed spurious error that occurred when manually deleting a summary record from a shared database.
Fixed naturaldate( crash that would occur if less than 3 patterns were supplied for the second parameter. Now this returns an error instead of crashing.
Fixed Panorama X Server error handling of malformed URLs (without a valid database name).
Error messages returned by web server to browser are now correctly HTML encoded, so special characters in the error message will be rendered correctly.
The GoForm statement now stops any secret windows before running, and the partially implemented DATABASE option was removed (it didn’t work).
Text Editor object now triggers procedure when exiting even if using pop-up editing and there is a choice list.
Fixed Software Update window to make sure it NEVER appears when starting Panorama Server, only client.
Fixed ability to set custom button names in the SuperGetPassword statement. (In previous versions of Panorama X you could not change it from Ok;Cancel.)
Fixed alert error when clicking on a notification that reported a server error.
Fixed crash in runningappinfo( if a process id is supplied that doesn’t correspond to an actual running process.
Fixed crash that could occur if a parameter to a call( function results in nil.
Added extra error checking in ZLOG. Don’t want ZLOG to EVER cause a procedure to abort.
Reset the database faux TS number when first uploading or doing a new generation of a shared database.
Removed link to outdated Denali FAQ page from release notes.
Panorama 6 Installer window no longer reports that 10.14 and earlier are not compatible with Panorama 6.
Fixed help markdown generation so that styles in the first paragraph of each topic render properly. There were hundreds of help pages with incorrectly rendered first paragraphs (mostly showing bare asterisks instead of italic text).
Incorporated user documentation corrections into help file. Thanks to Peter Newble, Thomas Cooper, Robert Ameeti, James Cook, David Thompson, Craig MacPherson and David Scott.

JamesCook · August 15, 2022, 9:59pm

As you can well imagine, I’m intrigued by this and the documented Web Only features.

One question that the documentation doesn’t answer - can more than one copy of a database be capable of updating it? For instance, if one person handles the programming and another handles the data, can they update their copy from the server, then upload changes, or…?

Don’t consider this a request for more if it’s not there. It’s just an effort to understand the possibilities and imagine how to put it all to work.

admin · August 15, 2022, 10:53pm

This isn’t really the intention of this feature. The intention is that the data is only modified on the server itself. In fact, the client will not allow the data to be modified. So really the answer to your exact question is that less than one client can update the data. If you really wanted to update the data from a client, you would have to to a New Generation the same way you would to add or remove fields. The database will be offline while this is happening. Probably what you would need to do is edit the data in a separate database, start the new generation for the web only database, import the separate database into the web only database, then finish the new generation and upload the new data. OR, you could manually upload the separate database to the server somehow, then write a web procedure that uses importdatabase to load it into the web only database (remember, the “replaceexisting” option is allowed for this type of database.)

In Panorama 6 Server you could manually install a single user database on the server. This sort of database could not be accessed from clients at all, so it was difficult to do things like update the code. But if you needed to do operations like removeunselected, this was the only way that could be done.

Panorama X does not allow you to manually install a single user database on the server. So up to now, there was no way to create a database that could perform operations like removeunselected or import while replacing existing data.

If you’re still reading this, you’re probably quite interested in server web publishing. You are also probably wondering why the heck I spent resources implementing a feature like this now. As far as I know, no one was asking for this (which surprised me a little bit). And resources for working on Panorama are definitely constrained.

However, this feature is needed for provue.com. The provue.com server has about a dozen databases that manage all aspects of Panorama X – account registration, payment tracking, new trials, calculating account usage, etc. These database have all been working for 6 or 7 years. Obviously 7 years ago there was no Panorama X Server, so all of these databases had to be implemented at that time using Panorama 6 Server. For the most part, the code in these databases hasn’t been touched for several years. I’ve decided it’s now time to update these databases and get rid of Panorama 6 on the provue.com server.

One crucial part of this back-end system is a database that processes incoming raw usage reports from each computer running Panorama and converts that into the final usage reports used for billing (and also email to you each month). This raw data needs processing that isn’t allowed in a shared database. In addition, this raw data needs to be archived and cleared out periodically – for performance reasons this data only contains limited recent data. But as mentioned earlier, shared databases really don’t allow for this kind of clear out. So currently, these tasks are done with a single user database on the Panorama 6 server. So the reason for the web only feature is that I needed it for this in-house application. Since it’s possible that some of you may need to set up similar applications someday, I documented it for anyone’s use.

This new web only feature is nicer than manually installing a single user database. With a single user database, there was no way to update procedures, but with the web only feature, code can easily be updated the normal way. The web only feature also allows you to easily download the data to a client, for example if you wanted to run reports. (I didn’t need this for my in-house application, but it seemed like a good idea.)

Why isn’t RemoveUnselected allowed in Shared Databases?

The rest of this note is kind of a separate issue, but I am guessing that if I don’t revisit this here someone will ask. I’m pretty sure I’ve discussed this before (even back in the Panorama 5/6 days), but probably some of you don’t remember or haven’t heard the explanation before. When a database is shared, all deleted records are tracked in a separate list. As more and more records are deleted, this list just gets longer and longer. The space isn’t so important, but this can slow down synchronization, because parts of this list have to be sent to each client as it synchronizes. So Panorama’s synchronization system relies on the fact that for most databases, deleting a record is a relatively infrequent occurrence.

In theory removeunselected (and similar features) could be programmed to add all deleted records to this list. However, I think this is a bad idea, because no matter how many warnings given, I’m certain that in many cases this would result in extreme performance issues caused by mass deletions of records.

Note - I said that the list of deleted records always gets longer and longer, but there is a way to clear it out. If you do a new generation with the Field Structure option checked, this will clear out the list. But of course that also means that all clients will have to download the entire database the next time they synchronize, not just recently changed data.