Converting Pan 6 to X

Panorama "Classic"
1

I have major rewrites and losses of capabilities in converting to Pan X. It may be less work to make the changes in Pan 6, then convert to X Following are several issues. It looks like my Calendar file is totally unsupported. I have around 10 files using Word Processor SOs. Pan X crashed opening these. My Partnership tax return procedure must open the previous year’s return to copy over numerous year ending balances into the current form’s opening balances. I use OpenAs “old Form 1065” and Grabdata functions. I would have to now close the current year’s file, open last year’s then load variables with the data, close the file, reopen the current year’s file and fill the fields from the variables. I use multi-record invoices and work orders that are grouped by common invoice and work order numbers. I GroupUp on the product code to total the quantities needed. However, I often sort by several fields, then use Group to not change the order of the records, like for product totals per day for the week… I have numerous Crosstabs that calculate and print incredible sales reports, things like product sales per customer per month. I use FloatingEdit to edit data in the Heading tile of a View as List form. Any comments and insights are welcome.

Greg

2

Greg, I feel your pain. Imagine how OverViewer owners felt when they had to “switch up” to Panorama. PanoramaX has the same name as Panorama(6), but they are different critters. I kept wanting to "bring things over and tweak them to PanX as necessary. But for me, it became clear that it was best to learn PanX as a “New App”. Start from scratch and watch all the videos and tutorials and implement the procedure concepts in Pan6 without trying to port the code.

Also, understand that Pan6 was at the end of a long, long evolution, while PanX is, relatively, just beginning. So there will be little glitches (like moving fields around in datasheet view).

One challenge is wrapping my mind around newer/better “best ways”. For example, embracing the “relational” concepts now available.

I do miss being able to “buy the book”, spend a weekend reading it, and gaining a mastery of the commands and functions (It worked with COBOL; it worked with PASCAL - I was younger then :grinning:). But that’s balanced out by the fun of discovering, “What, it can do this! And it can do this!” as you jump from connected topic to connected topic.

Remember, Apple made changes to the hardware and OS which required the Panorama rewrite. In theory, PanX will now be more stable and more able to withstand the whims of Apple software engineers. For example, I won’t miss having to discuss with a user why fonts change when they send a client a form.

3

IIRC, Jim has said those objects in Pan6 were powered by a third party plug-in he’d licensed. They’re out of business and a PanX version of them won’t be forthcoming. What you can do with Text Editor Objects and Rich Text will be as close as you can get to them.

Jim did add cross tab and summary features to PanX which are quite good. I did find one old crosstab trick I couldn’t reproduce in PanX and pointed it out in forum. Jim agreed it couldn’t be done exactly the same but a way of accomplishing the same analysis better nesting a cross tab within another cross tab essentially. And it took very little time to accomplish. It’s somewhere in the forum as are many other useful tricks.

Although View-As-A-List forms aren’t gone they are more problematic than in Pan6. They weren’t needed much by me in past so I’m no expert, but lots of folks have complained in forum. Jim has said it’s just not possible to make them work the old way now. Either use them in ways that still work or redesign your approach to use alternative tools. Text List Objects seem to be the usually proposed alternatives. And mostly those complaining eventually are happy with them. But, alas, life brings change whether we want it or not.

Old systems and hardware eventually die. In principle I can still run Pan6 under Parallels. Haven’t needed to for years, although I’m still working to transition from a couple other fossils while I still can. But I suspect advancing system versions and Apple Silicon will kill even that option. The critical thing is to retain the ability to do essential tasks, some how. Even if the preferred way is gone. And to retain access to essential data in some form, even if, temporarily or not, it can only be accessed in harder ways. The flexibility, speed and programability of Panorama, 6 and X, is a big asset there. If data is in Pan6 in some form you can likely get it out in some organized manner. Be it in large, complex csv or tsv files or whatever, and with suitable notes so that once your PanX skills have grown you’ll be able to re-import it into some not yet conceived database. If Pan6 files convert to PanX, even if the code, forms, etc don’t yet work perfectly you have the data. Stay backed up well and work on updating those forms and code. If circumstances force you to keep using 6 for some tasks consider writing procedures to automate your future forward data dumps from it. Try to keep a big picture in mind. One learned PanX trick may be applicable to multiple places on your conversion to do list. Learn once, apply quickly to multiple sites. While awaiting your next brainstorm work on the understandable but bulky mundane stuff. Which still shrinks the pile.

4

The fact that Datapak software has long gone out of business isn’t really the problem here. To protect against that possibility, ProVUE spent a lot of money on a source code license to the word processor code. So ProVUE isn’t depending on Datapak staying in business to continue supporting this code.

What wasn’t anticipated in 1994 when this code was licensed was that Apple would completely deprecate the APIs used by that code, as well as all code that existed for the Mac at that time. Even though ProVUE has the source code for the word processor, that source code is now useless, just as all of the source code for Panorama 6 is useless. Apple did provide a “bridge” that could allow that source code to continue working on OS X, that bridge was called “Carbon.” This bridge extended the life of code written for the original MacOS system by about 15 years. But ultimately with the release of Catalina this bridge was completely removed. There is no ongoing path for old MacOS source code – it just doesn’t work.

The Datapak word processing code uses a proprietary format to store styled text. Though I have the source code, the format of this styled text is not really documented in the source code, and Datapak did not provide any method to export styled text into some other format. In the time frame of 1994 I’m not really sure what other format would have been appropriate anyway. So, there is no way to export styled text from old Panorama documents. You can export the raw text without styling. This has do be done in Panorama 6, by using the documenttext( function. So if you want to bring over old word processing documents you’ll have to convert them to straight text before converting to Panorama X. Then in Panorama X you could add styling back again using Rich Text tags. There is no WYSIWYG styled text editor in Panorama X. It’s possible that this might be added eventually, Apple API’s support this. However, even if this happens it would not be compatible with the old DataPack format word processing objects. (The good news is since styled text is now supported by macOS, this format would be compatible with other word processing programs, for example copy/pasting style text from other programs.)

If you are using Panorama’s old "reminder* data then yes, this is not supported and will not be supported.

You would simply need to rename the old file with a different name to be able to open it.

You’ll simply need to make an extra field, use formulafill to fill this with data from the fields you are sorting, then use groupup on this combined field.

Crosstabs can no longer include multiple levels, but you can put multiple crosstabs on a form, linking them to acheive multiple levels as Tom mentioned.

Instead of using FloatingEdit you can simply create a dialog.

If a 500 year old house burns down and has to be reconstructed with modern materials and techniques, it’s not going to be exactly the same as before. Panorama 6 was based on technology that is long obsolete, basically the equivalent of 500 years old in this business. Panorama X is not an exact clone of Panorama 6, but it is about as close as it can be while using modern technology.

5

And an impressive amount of Panorama 6 moves right in without modification. A lot of the rest needs an adjustment or two. The amount that just doesn’t make it is quite small.

6

Jim,

Your better explanation of the Pan6 wordprocessor story ties into my current conversion to PanX project: SuperCard (successor to Hypercard) to PanX. SC developers also was blindsided by CarbonLib abandonment, but haven’t responded as well as ProVue. Although they’re still working on SC, hopes for 64 bit, Cocoa only SC are low. Panorama never has, nor would, claim to be an full HyperCard replacement. But for the HC subset I’ve been using it’s close enough.

One option SC folks added to original HC was Carbon styled text. I can get that exported as plain text, as styled text which TextEdit now opens fine, or as plain text also showing the tags buried in RTF (as seen via BBEdit.) I’ve noted Rich Text, when selected and copied from a TDO, pastes into TextEdit as styled text. Apple compliant code! I presume Apple’s API allows your Rich Text ‘interface’ to be interpreted into their styled text. From which the clipboard, as normal, receives all available formats then pastes the best supported one. Am I correct that an automated reverse conversion isn’t currently available within PanX?

Since WYSIWYG is possible, the reverse, a ‘styled’ to ‘Rich Text’ conversion, must also be. But I guess only after significant coding by you, which should’t be done until if and when you decide it makes sense to do. Styled text would be icing for my conversions. Plain text, or plain text with small amount of hand coded Rich Text will be adequate cake. And my saving delimitated styled text (TextEdit) exports allow adding that back later if/when Pan X grows into it. But I like icing!

The conversion may be possible outside of PanX. Are you aware of any such? I’ve spotted some RTF to HTML converters online. Maybe converting via HTML to Rich Text would be easier than one step from RTF. The tags seem closer. And if we’re willing to spend OUR time a graphical interface to at least partial Rich Text encoding/decoding might be buildable using Panorama’s tag tool set. But no need to invent a wheel if one already exists.

7

I wouldn’t say ProVUE was blindsided, I expected this for probably 8-10 years before it actually happened. Perhaps that’s why the SuperCard developers haven’t responded well – I gave myself a big head start.

That was intentional. Rich text was designed from the ground up around the Cocoa NSAttributedString class.

Am I correct that an automated reverse conversion isn’t currently available within PanX?

You are correct. I believe that is mostly possible, though that conversion wouldn’t always be perfect because rich text tags don’t cover 100% of the features available in NSAttributedString. It’s a very high percentage though.

FYI, RTF is a nightmare. I don’t plan to ever touch that. It’s not even really a standard – it’s just a mess. And RTF is not the format used by NSAttributedString. It’s also completely different than the styled text used in Carbon and pre-OS X versions of MacOS. (Note – I’m pretty sure that the Panorama Word Processor pre-dates the Carbon styled text you mentioned. The Word Processor was incorporated into Panorama around 1994, I’m pretty sure Apple didn’t have a styled text solution in MacOS at that time. That’s why DataPak went to the trouble of developing one from the ground up. It was about 100,000 lines of code, so not a trivial project. For comparison, Panorama X is about 350,000 lines of code, though Panorama X uses higher level languages than DataPak did so it’s not strictly comparible.)