Command control code confusion

I am trying to setup a toolbar button to export all my settings to a dated file in my DOpus folder.
I have a button with this function:
Prefs EXPORTSETTINGS=all,alltoolbars,filetypes,filters,images,prefs,toolbars TO "{home}\MySettings{date|yyyymmdd}.dps"

When I click it, the export settings progress bar does it's thing, and then informs me that settings were exported OK, but when I look in the DOpus folder, there's no file.
Actually, I cannot find the file it made anywhere.

What am I doing wrong?
Please help, thanks.

Not sure where you got the {home} argument from.

I just tried your command and gave it a proper path ...

Prefs EXPORTSETTINGS=alltoolbars,filetypes,filters,images,prefs,toolbars TO "C:\Documents and Settings\Steve\Desktop\MySettings{date|yyyyMMdd}.dps"

and it works fine.

(note: the MM instead of mm in the date argument - mm is minutes)

(also, the all argument makes the rest redundant)

If "home" is an env-var on your system then you should be able to use %HOME% (rather than {HOME}) as part of the path.

I just tried this, which uses %USERPROFILE%, and it worked here:

Prefs EXPORTSETTINGS=all,alltoolbars,filetypes,filters,images,prefs,toolbars TO "%USERPROFILE%\Desktop\MySettings{date|yyyymmdd}.dps"

I guess I was being hopeful.
/home is listed on page 165 of the DOpus8 PDF manual, under the PATH stuff. I was hoping it would work in the control code squiggle stuff too.
Is there any way I can use something like that, so that it copies the settings to the DOpus folder? I just prefer to keep everything in the folder relating to the app, rather than scattered all over the show.

Cheers.

Manually use the Opus path ...

Prefs EXPORTSETTINGS=alltoolbars,filetypes,filters,images,prefs,toolbars TO "C:\Program Files\GPSoftware\Directory Opus\My_Opus_Setup-{date|yyyy_MM_dd}.dps"

or with Opus 8.2.2.0 you can use {apppath}, as in ...

Prefs EXPORTSETTINGS=alltoolbars,filetypes,filters,images,prefs,toolbars TO "{apppath|dopus.exe}\My_Opus_Setup-{date|yyyy_MM_dd}.dps"

[quote]I guess I was being hopeful.
/home is listed on page 165 of the DOpus8 PDF manual, under the PATH stuff. I was hoping it would work in the control code squiggle stuff too. [/quote]

Look in your Opus configs directory. Apparently when it comes to exporting prefs, the /home system folder alias does not refer to the directory Opus program directory, rather it creates a "home" subdirectory under the configs subdirectory and in that, are the saved preferences (on my machine anyway).

I wonder if this is a bug? Or by design?

Ummm... he's just getting confused between external control codes and the builtin Opus aliases. As an alias "/home" should still point to the Opus install folder.

In any event, this actually raises an interesting feature request though. I think it might be rather nice to be able to use some of these aliases in external controls. For instance, the 'My Documents' virtual folder is not always in a %USERPROFILE% sub-folder... mine is on the D: drive. Being able to use something like {/mydocuments} could be handy at times since there's no standard environment var to use (as was the case in THIS situation) as an alternative. When I share certain buttons with friends who have seen the 'Opus light' they have to modify stuff like this to suit their systems.

[quote="JohnZeman"][quote]I guess I was being hopeful.
/home is listed on page 165 of the DOpus8 PDF manual, under the PATH stuff. I was hoping it would work in the control code squiggle stuff too. [/quote] Look in your Opus configs directory. Apparently when it comes to exporting prefs, the /home system folder alias does not refer to the directory Opus program directory, rather it creates a "home" subdirectory under the configs subdirectory and in that, are the saved preferences (on my machine anyway).[/quote]

The issue is with all aliases, not just /home.

I've had this in my issue log for about six months now. (I have about 40 such issues for which I'm still creating test cases, performing detailed analysis on, and verifying if they are still issues in the newest release.)

I believe it is by design, or more accurately by a lack of design. There are only a few references in the User Manual stating that Folder Aliases are supported by a given feature. This leads me to believe, that they are not widely supported throughout all raw commands. However, Jonathan Potter would know if this is the case or not.

I've polished up my issue report (as an enhancement request) and will be submitting it to GPSoftware right now. I will be referring them to this thread:

[url]Consistent Support of Folder Aliases]

Other users should show their support for this issue in the thread listed above.