Another big thanks for the Prefs expansion to support the .DPS files. But I have noticed that the EXPORTSETTINGS=all seems NOT to export the following:
The 'Images' contents (I am using a downloaded theme with images in it)
The toolbars covered by the regular settings dialog selection for 'Export all toolbars, not just those currently in use'.
Also, on a positive note I noticed that many of the values that were previously exported as hex data are now exported as string values - like the contents of filetypes.dpf. Thanks... it makes comparing configs much easier. But also there I have noticed that 'seemingly' for no reason other than testing import/export/import, terminating null characters are added to the ends of some strings in between I/E operations... Weird.
But LOVING double clicking on .DPS files to import them! Next up... context sub-menu's (man you guys really did add alot of stuff I asked for - YAHOO!)
[quote]
But also there I have noticed that 'seemingly' for no reason other than testing import/export/import, terminating null characters are added to the ends of some strings in between I/E operations... Weird.[/quote]
Can you give me an example of this? Does it cause any problems?
Well, there are a few slight variations on what I'm seeing... all of which seem to be related to a basic shift in how some data is now exported to the .DPS settings from the registry. Anyhow, I've noticed that along with some command key data for given actions 'function' values being dumped out in string form to the .DPS files... where that data had previously been stored under the (Default) string values it is now also appearing in an explicit "@" string value. For instance, at the moment I've got the following discrepencies:
After I initially exported my first set of settings using the command dopusrt /cmd Prefs EXPORTSETTINGS=all TO {sourcepath}"{dlgstring|Specify name of exported settings file...|"my dopus settings.dps"}", I end up with the following filetypes.dpf entry:[HKEY_CLASSES_ROOT\AllFilesystemObjects\opusdrop\Copy_to_New_Folder_Here\command]
@="sync:dopusrt /cmd Clipboard COPY \0
sync:dopusrt /cmd CreateFolder \"{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}\" READAUTO \0
sync:dopusrt /cmd Clipboard PASTE \0
sync:dopusrt /cmd Go {sourcepath$} "Previously, (pre 8032) this same data was exported to the .DPS files with a @=hex(7): prefix followed by the string data above in a hexdump format. But hey, I like the string dump better anyway... However, I believe I then 'Imported' the settings above using the command dopusrt /cmd Prefs IMPORT "%1" IMPORTSETTINGS. I subsequently 'exported' my settings again and now see the data above expanded into the following:[HKEY_CLASSES_ROOT\AllFilesystemObjects\opusdrop\Copy_to_New_Folder_Here\command]
@="sync:dopusrt /cmd Clipboard COPY \0
sync:dopusrt /cmd CreateFolder \"{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}\" READAUTO \0
sync:dopusrt /cmd Clipboard PASTE \0
sync:dopusrt /cmd Go {sourcepath$} "
"OpusFlags"=dword:00000000
[b]"@"="sync:dopusrt /cmd Clipboard COPY \0
sync:dopusrt /cmd CreateFolder \"{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}\" READAUTO \0
sync:dopusrt /cmd Clipboard PASTE \0
sync:dopusrt /cmd Go {sourcepath$} \0
"[/b]******** sorry for writing such long posts man... I appreciate the time taken to review this stuff ********
So while this is strange, it doesn't seem to be a 'problem' - I've just got weird 'duplicate' data in this actions command key... But, the other variation I have on this is:
First export:[HKEY_CURRENT_USER\Software\GPSoftware\Directory Opus\Filetypes\Groups\{D8E72F63-E7FC-4AF4-87C8-A08E5B019820}\opus\Encode_with_Monkey's_Audio\command]
@="sync:\"C:\\Program Files\\Monkey's Audio\\MAC.exe\" {filepath} {filepath|ext=ape} -c5000 -v\0
Delete"After Import/re-Export:[HKEY_CURRENT_USER\Software\GPSoftware\Directory Opus\Filetypes\Groups\{D8E72F63-E7FC-4AF4-87C8-A08E5B019820}\opus\Encode_with_Monkey's_Audio\command]
"@"="sync:\"C:\\Program Files\\Monkey's Audio\\MAC.exe\" {filepath} {filepath|ext=ape} -c5000 -v\0
Delete[b]\0[/b]
"
In THIS case, the difference is that the (Default) key is empty, and I now just have the additional explicit "@" data value in the command key. My context menu action to encode .WAV files to moneky's audio (and another similar one for Lame/mp3) no longer appears when I right click on .WAV files and sure enough, when I go back into the Dopus File Type Editor, while the names of the actions are still listed there they are ... and contain no actual command data.
Items of Note- The last context menu action above that I'm having an actual problem with is something I had defined for a File Type group I created for Wav files (forget why I did that instead of just using the .WAV system file type). It's also 'possible' that somewhere in the middle of testing the double click action I set up for .DPS files (to 'import' them) and the button to 'export' my settings that I may have used the Prefs IMPORT "%1" IMPORTSETTINGS command to test importing one of my older (pre-8032) .DPS files? Perhaps this may explain some of this (Default) vs. "@" key transposing that seems to be occurring?
[quote]
I subsequently 'exported' my settings again and now see the data above expanded into the following:[HKEY_CLASSES_ROOT\AllFilesystemObjects\opusdrop\Copy_to_New_Folder_Here\command]
@="sync:dopusrt /cmd Clipboard COPY \0
sync:dopusrt /cmd CreateFolder \"{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}\" READAUTO \0
sync:dopusrt /cmd Clipboard PASTE \0
sync:dopusrt /cmd Go {sourcepath$} "
"OpusFlags"=dword:00000000
[b]"@"="sync:dopusrt /cmd Clipboard COPY \0
sync:dopusrt /cmd CreateFolder \"{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}\" READAUTO \0
sync:dopusrt /cmd Clipboard PASTE \0
sync:dopusrt /cmd Go {sourcepath$} \0
"[/b][/quote]
Ok, this appears to be a bug. It looks like the @ (meaning default value) is being interpreted as an actual named value on re-import, meaning the default value isn't being correctly set. This must have crept in in the changes for the Unicode version (Unicode is also the reason multi-line string values are exported as strings now instead of binary data).
Ok cool... I figured that the unicode support might have had something to do with the switch to string dumps vs. hex.
With all my blabbing about the "@" symbol interpretation, I did not ask whether or not you had any time to look into the missing toolbar buttons and [b]Image[/b] folder content when using the Prefs command to do the export... It does NOT occur when using the regular Settings Import and Export dialog. Also, I hadn't realized before, but it looks like [b]Sounds[/b] is also among the missing exported data.
Also, back to the unicode/@ related issue... I don't want to do anything too destructive requiring a re-install, but I've got a bunch of misplaced registry data now due to the issue. I've also made a bunch of settings changes during my 8032 eval that I'd like to hang onto... What's your thoughts on me manually moving the misaligned data into the (Default) values and whacking the "@" symbol entries directly from regedit? Not sure if Dopus keeps any sort of binary mirror or index to any of the registry settings that I might inadvertently fubar by trying to correct my settings...
We'll put out an update that fixes this soon. In the meantime I'd advise not importing/exporting too much. To actually fix one of these re-exported files will be easy for you to do - just load it in a text editor and search for "@" (with the quotes). Every time you find "@" remove the quotes, and then under the same key if there's an @ by itself just delete it.
Speaking of 'fixing' one of the exported files affected in this way; say I was to manually edit one of the .dpf files to correct these errors... if I then re-zip all this stuff back up, and rename the zip file back to .DPS... can I then import it? When last I looked into doing something like this, the resulting zip file was not the same size as the original .DPS file (even using the internal opus zip engine), so I was hesitant to even bother trying to import it.
I actually tried the max compression and the resulting zip file is still a hair bigger than the origina DPS file exported by Opus... you holding out on us with maximum insano super compression? LOL...
Ok, so now with the official 8.1.0.1 release, if I use Prefs IMPORTSETTINGS=all not all the settings are actually imported... but there is a replaceall switch that does the trick, I guess this is a safety switch which is cool.
However, still for exporting; Prefs EXPORTSETTINGS=all does not actually export everything. If you add the individual items (like images, alltoolbars, sounds) then you get them, but shouldn't all do the trick? Minor at this point since just adding the other swicthes does the trick... but for someone who doesn't know this and relies on the 'all' option and then re-installs his system or something - woopsy.
