The old format is still supported in “read-only” mode for compatibility with existing databases. The data in an old format dictionary can still be accessed, but will automatically be converted to the new format if any changes are made.
Following a database conversion from P6, I have not been able to access the contents of a P6 dictionary containing text stored in a permanent variable in PX. The PX dictionary statements and functions I have tried returned “… not a valid dictionary” or similar error.
How do I make a change which will automatically convert the dictionary to the new format?
If you have permanent variables that contain binary values (like dictionaries), you must use the Binary Data Wizard to designate these variables BEFORE you import the database into Panorama X. If this isn’t done, Panorama X will attempt to convert the data to Unicode, which will corrupt it. That’s why you are getting the error message.
The last five slides of the Converting from Panorama 6 to X video show how to install the Binary Data Wizard into Panorama 6 and designate the variables. Go to about the 36:30 minute mark in this video.
Once this is done you don’t have to anything special in Panorama X, you can simply use functions like getdictionaryvalue(, listdictionarykeys(, etc. However, if you modify the dictionary with setdictionaryvalue, it will be converted to the new format. That really doesn’t matter to you because you will never be looking at the raw binary value anyway. The only possible consequence would be if you wrote the dictionary to a disk file – if you did that, the file would not be readable by Panorama 6. The reverse is possible, however – if you write a dictionary to a file in Panorama 6, that file will be readable by Panorama X.
Dictionaries in Panorama 6 were just tagged text, but in Panorama X they are binary, and when they are placed in a field, it needs to be a binary field. A lot of complications are avoided by designating a Pan 6 dictionary as binary before converting.
That’s more or less true, but the tag characters were not defined characters in the MacOS Roman encoding. So in that sense, they were not “legal” text, and that’s the problem. When importing permanent variables into Panorama X, unless you designate the variable as a binary value the text in the variable is converted from MacOS Roman into Unicode. But that conversion doesn’t work correctly because of the “illegal” characters.
When you designate a variable as binary, it is brought into Panorama X untouched. The text inside the dictionary elements is still in MacOS Roman encoding (inside the binary value). If one of the dictionary functions sees a dictionary in Panorama 6 format, it converts it “on-the-fly” into Panorama X format, including converting the text from MacOS Roman to Unicode.
Designating a Pan 6 dictionary as binary before converting isn’t just about avoiding complications – it flat out won’t work if you don’t do so. Fortunately this is a one time thing, easy to do, that only affects a very small number of users that were storing dictionaries in permanent variables. I wish it affected more users – dictionaries are a great feature that I use a lot, but never really caught with very many Panorama developers.
Panorama 6 didn’t make a distinction between text and binary values. Because Panorama 6 didn’t worry about text encoding, it was your choice whether to access data as a text value or binary value. (Of course, if you chose incorrectly, there would be problems.) Since Panorama X now explicitly uses Unicode encoding, text and binary are no longer interchangable. So you must explicitly specify whether a field contains text of binary values. (Variables also keep track of whether they contain text of binary, but that is done for you automatically, just as you don’t explicitly specify whether a variable contains text or a number.)
The tag characters were chr(254) and chr(255) which the ASCII Chart shows as ˛ and ˇ respectively. According to the character viewer ˛ is an ogonek (Unicode character 0x02DB) and ˇ is a caron (Unicode character 0x02C7). The characters are unusual, but they are defined.
Several years ago I began storing arrays in dictionary values in the course of which I noticed those unfamiliar characters; apart from them the P6 dictionary looked like pretty normal text. This may be why I hadn’t considered it could be binary.
The same dictionary is now finally in PX binary format –– there certainly is a big difference. I won’t be messing around with that, but then I won’t have to.
Because of my brushes with dictionary encoding, your robust exchanges above were actually quite interesting, believe it or not.