Consistent Support of Folder Aliases



------------------------------------------------------------- Tracking Number: 330011825585 Support Issue: Program Suggestion Submission Date: 4/28/2006 7:27:14 AM -------------------------------------------------------------
This has already been logged with GPSoftware, it is posted here for others users to be aware of and to invite them to add their support and insight to.


Opus Folders Aliases should be supported across all Raw Commands.


Opus provides a folder path alias system whereby a user can use “Shortcuts” to refer to standard system paths. For example, Go /mydocuments would list the current user's My Documents folder. (See the GO command for a full list of predefined Folder Aliases.) The Folder Aliases section in Preferences allows users to add as many custom folder aliases as they like; they can refer to any folder or path, including FTP and ZIP files, even network paths.


This is an enhancement request. However, it may be a Bug or a Design Deficiency, depending on the current intended design of several Directory Opus features and raw commands.

STEPS TO RECREATE PROBLEMATIC SYMPTOMS:[ol][li] Download the attached toolbar and display it in DOpus.[/li]
[li] Open the left pane a lister to a folder with files you can copy.[/li]
[li] Click on the Create Test Folder button:

CreateFolder %SystemDrive%\testdir\testsubdir READAUTO=no NOUPDATESETTINGS

[li] In Preferences > Favorites & Recent > Aliases, add this Alias:[ul][li] Folder: %SystemDrive%\testdir\testsubdir[/li]
[li] Name: TestAlias[/li]
[li] Click [Apply][/li]
[li] Click [OK][/li][/ul][/li]
[li] Click on the Go Test Folder button:


Expected Results: Opus should list %SystemDrive%\testdir\testsubdir in the right/bottom lister.

Actual Results: Equal expected results – correct
[li] In the left pane, select a file to copy and click on the Copy File to /TestAlias button.

Copy To /TestAlias Go REFRESH=ALL
Expected Results: Opus should list newly copied file listed inside of %SystemDrive%\testdir\testsubdir in the right/bottom lister.

Actual Results: Equal expected results – correct
[li] Click on the Export Prefs to/TestAlias button.

Prefs EXPORTSETTINGS=all,alltoolbars To "/TestAlias\Alias-Test-Export.dps" Go REFRESH=ALL
Expected Results: Opus Preferences Export should display a progress bar followed by a confirmation dialog that states the settings were exported successfully. Opus should subsequently list a newly exported preferences file, Alias-Test-Export.dps, inside of %SystemDrive%\testdir\testsubdir in the right/bottom lister.

Actual Results: Opus Preferences Export displays a progress bar followed by a confirmation dialog that states the settings were exported successfully. Opus does not subsequently list Alias-Test-Export.dps inside of %SystemDrive%\testdir\testsubdir in the right/bottom lister. – incorrect
[li] Depending on how you have DOpus configured to store settings do one of the following:[ol][li] If you are using user-specific configuration settings, click the List User-Specific Configs button

Go "%AppData%\GPSoftware\Directory Opus\Configs" OPENINRIGHT

[li] If you are using PC-specific configuration settings, click the List PC-Specific Configs button

Go "%ProgramFiles%\GPSoftware\Directory Opus\Configs" OPENINRIGHT

In the test script above, the GO and COPY TO raw commands both work well using a Folder Alias, however Prefs EXPORTSETTINGS TO does not. Therefore, at least one Directory Opus raw command does not fully (or correctly?) support Folder Aliases. However, there may also be others which users have not yet stumbled on.

Folder Aliases should be supported by all Directory Opus commands and features that accept a file path, in a consistent manner.

It is reasonable (and intuitive) for users to attempt to utilize a Folder Alias in lieu of discrete file path anywhere that Directory Opus might accept a file path. Ensuring consistent Folder Alias support across the Directory Opus will shorten the adoption curve for new users by making the application more intuitive. Such consistency also facilities the intended design of exporting preferences, where users are encouraged to share techniques with one another. Relying on Folder Aliases over discreet paths makes custom commands more machine independent. (934 Bytes)

If I didn't know better I'd assume you were being paid by the word. :slight_smile:

I agree though, it's a good feature to add.

Yeah, I know its wordy. But over the years, I've learned to leave nothing ambiguous or to chance. On some issues, if I don't go through the painstaking documentation, I miss important things the first time, or worse forget about them after I've found them! Worse still, the person who receives the report may be having a hectic day. I figure if I really want it fixed, the least I can do is help out by submitting a good issue report!

Someone will come behind me a couple months from now (maybe even I will) and will want to test if this is still a issue or just wrap their head around it again. This thread now immortalizes the issue and includes a test case Jon and Greg could use to test any work they do on this issue. New users can also read this thread (or be referred to it) if they have a similar issue. it saves time in the long run.

Well, I definitely don't think it's a bug or a design flaw... the aliases are really only ever mentioned in the context of the 'Go' command and related favorites type functionality.

Anywho... I see unleash the folder aliases for use in external control codes. Woohoo... good times!

Hi, i think it would be indeed a good idea to have the folder aliases across all commands...

The first time i noticed that problem was when we started sharing buttons with my co-workers

We try to use folder aliases in our customs buttons/toolbar/etc., so that when we share them, we just have to change aliases

Well, in any case a vote for it !

Cheers, Nicolas