GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Adding Explorer Search Command

I'd like to be able to add a context menu command for folders (in all of the folder tree, list pane and pathbar) that will open Windows Explorer (1) in the selected folder and (2) with Explorer's Search bar open. Is this possible in DO 9.1?

Try this : [url]Open actual directory in Windows Explorer?]

Thanks, but I see I mis-phrased my question. It's not the Explorer side of things I'm looking for, but how to do from in DOpus. I'm not sure I need to be writing XML, nor figuring out how to plug the XML into some part of DOpus. I see now that I can probably do what I want by defining a new command using DDE via DO's File Types dialog box.

The XML represents a button.

See this FAQ:

[How to use buttons and scripts from this forum)

OK, thanks Leo. However, just running Explorer and setting the initial folder via the command line (which I know how to do) doesn't quite get there - the important requirement I have is that Explorer opens with the search bar (rather than the folders list or task list).

As far as I can see, this will need DDE commands thrown at Explorer, but therein lies the problem: it seems that when DO is running it provides the Explorer-equivalent DDE server AppNames and Topics, so any use of these will go to DO instead of Explorer.

What I really want to accomplish here is to access Windows Search 4.0 (or the Explorer search companion) initialised with a folder selected in DO. I know that DO supports Google Desktop, but we do not use that (for a number of reasons). At this point, using DO would appear to preclude easy access to Windows Search, and that will prevent the rollout of DO here.

You could turn off Opus's Explorer Replacement setting (Preferences - Launching Opus) as a quick way of solving the problem (while obviously losing the ability to double-click folders to open Opus).

Which version of Windows are you using?

Do you know what the DDE commands are?

I don't know much about Windows Search but I can try and figure it out.

OK, I've (mostly) solved this one using a different approach. The following VBScript will accomplish opening Windows Search/Explorer search companion at a specified folder:

[code]dim dir, oShell, ssfDRIVES
ssfDRIVES = 17

If WScript.Arguments.Count > 0 Then
dir = WScript.Arguments.Item(0)
dir = ssfDRIVES
End If

Set oShell = CreateObject("Shell.Application")
Set oShell = nothing
Once saved in a .vbs file, it is easy enough to invoke this from a custom toolbar button, say like this...


WScript "<yourpath>\ShellFind.vbs" {sourcepath$}


<?xml version="1.0"?> <button backcol="none" display="label" textcol="none"> <label>Shell_Find</label> <tip>Open a shell search window at the current folder</tip> <icon1>#find</icon1> <function type="normal"> <instruction>Shell_Find</instruction> </function> </button>

Similarly, the VB script can added to the context menu of folders by adding to the "All Folders" file type.

The only thing I can't work out is how to add a context menu item to drives in the DO pathbar. For instance, if the pathbar has "> My Computer > C" I want to be able to right-click the "C" and have the custom menu item appear. Is there any way I can do this?

There is. Go to Settings -> File Types and expand the bottom section of the list (System File Types). Wait for the list to build and near the top you should see something called b Drive[/b] -- the (NONE) means the type has no extension -- which is the file type for drives.

Edit that and you can add a command to its context menu.

If you want the context menu to appear in both Opus and Explorer then use the "Run an application" type. If you only want it to appear in Opus, use the "Run an Opus function" type instead.

The command would be this, I think:

WScript "<yourpath>\ShellFind.vbs" "%1"

(I used "%1" instead of {filepath$} so that it will work in both Opus and Explorer.)

Once you're all done and happy with how everything works, it might be worth posting the finished details into the Buttons & Toolbars forum, if you want. I bet other people will find it useful.

PS: You don't need to create the Shell_Find user command unless you want to. You can put the command straight into the button.

User commands can be useful if you want to re-use the same command in lots of places (and then only have to edit one thing to change what all of the things that refer to it do) but otherwise they just add an extra layer of indirection. I almost never use them myself, FWIW.

Ah, thanks - I missed that.

I find that if I use the "Run an Opus function" type, drives on the pathbar (in DO) don't show the menu item, whereas they do if I use the "Run an application" type.

I will do that. Before then, however, what I'd like to do is place the vbs file in the same folder as DOpus itself - that way it can be found irrespective of where DOpus is used from. However, I haven't found a way to specify the DOpus folder in commands. Using {apppath|dopus.exe} doesn't work if DOpus is being run from a USB drive. is there some other way that can be used both in buttons and "Run an application" items?

You're right. I forgot that the drive context menus are always built by Explorer, even in Opus.

Hmm... There is the /home alias which will work with USB installs, but I don't think aliases will work with "Run an application" type commands, since Explorer won't understand what they mean.

You could probably create a batch file on the USB drive which sets an environment variable to the right path and then runs dopus.exe, and use that instead of running dopus.exe directly. Then you should be able to refer to the env-var in the command. Maybe there is a more simple way but I can't think of it.

(I guess you could also copy the script to %TEMP% and make the button run it from there, which would save having to work out the USB drive's path and so on.)

The trouble with the environment variable approach is that it will work for DO run from a USB drive, but not from a standard installation (unless the env var is created manually, of course).

I'm not keen on using the TEMP folder either, as that will involve extra setup, and will not survive temp file cleaning, for instance.

Not to worry, though - it's not the most crucial feature, so I weill go with what I have. Thanks for your assistance.