Command Line option to launch Dopus with two given folders?

Hi,

Is there a way to launch Dopus and provide it with two folders to open (left and right)? Seems like something that should be trivial to do, yet I couldn't find it.

In general - does it have command line options? I couldn't find any documentation on that.

Thakns

Using dopusrt.exe you can send any internal command to Opus for processing, so for example:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go NEW C: DUALPATH D:

This would open a new Lister, with C: in the left display and D: in the right.

Maybe, but it seems to be subject to the users preferences setting for launching new listers.

Oh boy I'm in deep soup now. I can't believe I just added an addendum to what Jon said.

But as long as I'm swimming in soup ronenlevi brings up an interesting idea. To be able to launch an Opus lister in a totally different way from the norm.

Thanks.

Just one correction about the command line:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go NEW Go C: DUALPATH D:

And how does it depend on the lister preferences?

You shouldn't need that extra Go.

Ah, the NEW argument can take a qualifier which is why you had to add the extra "Go" (any word would've done, in fact). This works and is cleaner:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go C: DUALPATH D: NEW

You can give NEW various qualifiers to specify which components the new window has, e.g. tree and so on, for example:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go C: DUALPATH D: NEW=tree,viewpane,max

That will open a maximized window with the tree and viewer pane switched on.

The = after NEW is optional so this command is exactly the same:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go C: DUALPATH D: NEW tree,viewpane,max

Jon's original command was like having NEW=C: which was why adding something between the NEW and C: fixed it.

And that's where I took my wrong turn last night Nudel. In my erroneous test I was using only the NEW argument alone and I had it before the C: and D: paths. When I do that Opus opens the left pane in My Documents instead of C:\

However if I change this:

dopusrt /cmd go new c: dualpath d:

To this:

dopusrt /cmd Go NEW=max C: dualpath D:

Or to this:

dopusrt /cmd go c: dualpath d: new

then Opus opens in the specified C:\ and D:\ locations.

As I live and learn.

I actually had this typed up on my issues list. But never once thought about rearranging the options.

There are a few raw commands where the order the options are listed dictates success or failure. Here's another one:

This works:

Go OPENINLEFT /mycomputer

This works:

Go /mycomputer OPENINLEFT 

This works:

Go /mycomputer OPENINRIGHT

But this does not work:

Go OPENINRIGHT /mycomputer

Both OPENINLEFT/s and OPENINRIGHT/s are switches and take no qualifiers.

This behavior is the same if the path is a local drive, network share, or an alias.

That's because OPENINRIGHT can take extra parameters and you're relying on "/mycomptuer" being paired with the implicit PATH argument which won't happen if it's paired with something that can take extra parameters.

If you explicitly give the PATH argument then you don't have to worry about the order at all. Both of these work:

Go OPENINRIGHT PATH=/mycomputer
Go OPENINRIGHT PATH /mycomputer

Your last example is equivalent to:

Go OPENINRIGHT=/mycomputer

OPENINRIGHT is actually a /O argument (optional parameters) for the Go command. It's only /S for Favorites and Recent.

Well, I guess the documentation needs to be updated:

[quote="The authors of the Directory Opus 8 Help File, under the Raw command: Go"]
OPENINRIGHT/S: The specified folder will be read into the right-hand file display of a dual-file display Lister, irrespective of the current source file display. Can also be used with ROOT and UP.[/quote]

[quote="The authors of the Directory Opus 8 User Manual, under the Raw command: Go, on page 165"]
OPENINRIGHT/S: The specified folder will be read into the right-hand file display of a dual-file display Lister, irrespective of the current source file display. Can also be used with ROOT and UP.[/quote]Both of these sources list this option as a switch. I also searched through the Changes.pdf and there is no mention of this option not being a switch.

[Edit]

Since it is undocumented, what extra parameters does GO OPENINRIGHT take?

[/Edit]

Also here:

[quote="The authors of the Directory Opus 8 User Manual, under the Raw command: Go, on page 201"]OPENINRIGHT/O
no parameters
Read path into the right-hand file display (switches Lister to dual mode if not already)[/quote]

This page does show /O, but then says there are no parameters.

The drop-down argument menus in the (advanced) button editor are a definitive place to look for argument lists and types. They correctly show OPENINRIGHT/O and list the two possible parameters, horiz and vert.


Ah ok, the docs are wrong in this regard - although the command template shown at the top of the Go - Raw Command section do list OPENINRIGHT/O correctly, and also the Command Summary Table in Appendix C of the manual.

Nudel,
Many long-time members on this forum, and the email list before it, have always "suggested" that new users to read the manual or the help file to get a better grasp about the many features of Opus. (I agree that reading the Opus manual is a must.)

But I'm sorry friend, the GUI should not be, and is not, the "definitive place to look" for options on commands, as evidenced by another issue on my list:

[quote]20. Missing Advanced Command Editor Option Menu for Copy To command:

Copy To/K=<Specify>  (or similar syntax description)
Copy To/K=ask
Copy To/K=ask$

That is to say the To/K argument of the Copy command should be listed as a submenu with the above argument options on it. This should be similar to how other command arguments are listed in the Arguments menu of the Command Editor (e.g. Copy WHENEXISTS/K).[/quote]

This is just one command option whose parameters are missing from the GUI that I typed up already. There are others I've come across that I didn't have time to type up.

There really is no definitive place for a user to get a complete handle on Opus features. Users who really try to adopt a new application will read the manual. And eventually, everyone at least spot reads portions of the manual to figure something out. That should be the definitive body of knowledge on Opus.

If we tell people to RTFM, the FM should have the goods.

This just gave me an idea :bulb: Perhaps GPSoftware should consider a fitting the Opus Resource Center with a WIKI manual. I've seen (and participate in) some of these at other technical sites.

It should help free-up Jon and Greg's time for development. Because searching through old forum posts for these tidbits of undocumented knowledge can get tedious, and often doesn't net results.

Hi Ken,

I've been reading this thread with much interest tonight.
Each time, just as I have been about to post a reply,
a new wave of replies gets posted !
It's really page 164 Ken.

It's good to read your posts Ken, I appreciate them.
The current state of the DOpus manual is a topic that goes back to the days preceeding this forum.
There was an e-mail list then. :blush:
Ahhh... this subject resulted in some proactive actions by Admin.

Anyway Ken, it's good to see you aboard.
I'm already learning from your posts, but I see other things from time to time.
I have no doubt that you are, and are going to be a valuable member of this forum.
Not so certain of myself, but sometimes I get a good thing going !

On a personal sidenote, my Mom got food poisoning at the Detroit International Airport last weeekend.
She was returning from New York after visiting my Sis who is in the hospital.
She bought a well cooked hamburger with lettuce at Max and Irma's at the airport between 2 and 3 PM Saturday.
She had eaten only a few soda crackers earlier in the day.
She arrived Green Bay at 5:30.
By 7:00 PM she was extremely sick with an loose stools and a vomit.
It didn't clear for almost two days !
Handwashing !!!

                               Regards,
                               :opusicon: Porcupine

The problem with the manual is it's frozen in 8.0.0.0 land. :frowning:

I said the GUI is definitive because it is built from the same templates which are used to parse the arguments. The "ask$" thing is perhaps a special case, or just something that was overlooked. The /O, /S etc. will always be definitive in the GUI and extra/special things like ask$ are as likely (more IMO) to be missing from the manual as from the GUI, so I'd still say look in the GUI for the definitive command templates (but by all means read the manual first to get an overview and description of what things do).

I mentioned this last time I met up with Greg in London. I think it's worth investigating as that way whenever we notice something is wrong or out-of-date in the manual we can improve it.

I don't know how much effort it would take to set up and I'm not sure how well a Wiki can be printed. It would be a shame for the printable and online manuals to diverge, but I think that's better than a manual which isn't updated when the program is.