Find *.jpg IN "D:\snapshots" CLEAR SHOWRESULTS=tab
Set COLUMNS parent,parentpath
(ie. search results shown with the columns specified)
At the moment, only the search results appear. No commands afterwards seem to be executed.
I would also like to be able to specify size/position of the columns. However, upon checking the manual, this is only possible with the COLUMNSADD argument (,) etc
which means i would first have to remove all unwanted columns (which could vary each time), followed by columnsadd.
Since it would be much simpler/shorter to just specify these things once, may I suggest this as a feature request - ie. (,) arguments available with the 'Set COLUMNS' command.
I'm sure there is still a case where you might want to be able to do this in the same manner you're trying now (i.e. everything specified in commands in the button)... but are you aware you can achieve what you want by defining a folder format to display the columns you want for your search results?
For instance, even if you don't ALWAYS want all searches to use the columns you're including here in this question... then perhaps what you can do is create a folder format with the desired columns using a "wildcard path" format. Example:
create a wildcard path format with a path of coll://TEST*
modify your button slightly to run: Find *.jpg IN "D:\snapshots" CLEAR SHOWRESULTS=tab COLLNAME=TEST
Hi, Been experimenting with Dopus quite a lot for the past month or so and didn't notice your response. Thanks!!
Was not aware of that. The 'wildcard path format' solved that problem and opens up some nice possibilities.
Still have questions regarding stacking commands together though...
For example, I would like
Find RECURSE IN E:\images E:\private
Select *.(jpg|mp4)
Copy Move
(Moving pics/sounds from the memory card to another folder on my computer).
But any command after the find operation is not executed. Dopus is usually capable of waiting even for external programs to run/finish etc. and continuing
A similar dopus example that DOES work for instance
Go P:
Set FLATVIEW=MixedNoFolders
Select *.jpg
Copy Move
etc.
etc.
Essentially I would love to automate tasks AFTER various searches, but currently cannot.
Your button codes doesn't work because the second line contains commands that still refers to the path which where the source when you started the button.
When your source is C:\ and you start one of your buttons the select, set,copy or whatever commands in the second line doesn't know anything about the collection and new tab you started in the first line.
To get around this you can try to:
add a line with Go [path] between the first and second line
provide the full path of your files to the command like copy coll://TEST*.jpg
use dopusrt /cmd to execute the second command
For more complicated things you can use a commandline tool like nircmd.exe in combination with dopusrt.exe. This excellent little tool can define a time to wait before executing the next line, send keystrokes and much much more. You can also write several lines to a textfile with extension .ncl and use the script argument like nircmd script "C:\my command.ncl"
@Kundal
I like the nircmd.exe suggestion. It could come in useful, but I would rather not have to use it in this scenario.
[quote]Your button codes doesn't work because the second line contains commands that still refers to the path which where the source when you started the button.
When your source is C:\ and you start one of your buttons the select, set,copy or whatever commands in the second line doesn't know anything about the collection and new tab you started in the first line.[/quote]
Judging from my experimentation, once you 'Go' to any path (ie the lister first changes to that), any commands that follow it take place with that new path as source? Hence commands like 'READAUTO=no'. I assumed after executing a 'Find' command, it's like 'going' to the results collection.
Though I noticed, for example, the 1st group of commands ignores the 2nd line, whilst 2) and 3) do not.
Go ..
Select All
Go {sourcepath}../xyz
Select All
(where xyz is a subfolder of {sourcepath})
Go [path]
Select All
@Leo
I was just wondering why lines cannot be run after certain commands. Like a dead end. Any clarity on this?
Yes I could use a copy filter for copy operations, but what about other operations? Rename etc.
For me:
Find RECURSE IN ...
is like 'flatview' for a very specific group of folders only. Whereas I CAN follow flatview with something else, the problem in all cases is nothing can follow the 'Find' command. In fact, neither 'Go ..'
It just seems intuitive to be able to follow up the Find (or any other) command with others -- in stepwise fashion. Search results are a good starting point from which to automate other tasks, without having to press multiple buttons in succession.
DOpus needs to know the exact path to make it the new source. It seems that Go .. or Go UP doesn't really provide this information.
Why not? Calling a nircmd script with the following command is working for me (Select All after Find):
exec show "C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Find *.jpg IN D:\ RECURSE=yes COLLNAME=Test
wait 3000
exec show "C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Select all
The problem with this example is that you'll have to adjust the time for the wait command to the time DOpus needs to complete the search. Would be much better of course if DOpus could do the job itself.
I'm not sure why "Go .." behaves differently to "Go UP" in this particular case (I haven't tested/confirmed it but I'll take your word for it), but as a general rule, if you are changing folders and/or selecting things in commands with any aim other than changing what Opus displays, then there is usually a better way to do that.
It may work most of the time, but it's a fragile way to do things. e.g. If you accidentally click on something at the wrong time, you will mess up the selection and change which files the command runs on.
Use a command which does what you want to do by itself, instead of "scripting the user interface" like you are doing. The UI is for the user, not for commands. Most commands in Opus can be recursive and use wildcards or filters, or can be given a path or file to work on without you having to change the lister to that path or select that file.
They don't behave differently. With both commands the following line doesn't work on the new source while e.g. Go [path] is working.
My nircmd script should only be a simple example how it's possible to apply another command to files in the Find-results after a Find command. It shows that the problem with the Find command seems to be that in contrast to other commands DOpus doesn't wait until it's finished before executing the next line. Perhaps this could be improved.
You can use the same recursive filters which Find can use with most of the commands that might need them, so there should be no reason to using the Find command, and create a messy temporary collection, just to pass some filenames to other commands.
As I said, if you are "scripting the user interface" then there is probably a better, more robust way to do what you are doing.
I understand what you mean and agree with you. Looking at the first post again the original problem was to configure the display of the find results and Set COLUMNS parent,parentpath didn't work after the Find command. I think this is solved by what Steje suggested and what I suggested by "changing the order of the lines".
For all other operations like copy, rename etc. there are better ways than doing a Find first. So it's not really necessary to make DOpus wait until the Find has completed to apply further commands.
Just combine both commands like this:
Set COLUMNS=parent,parentpath COLUMNSADD parent(1,120),parentpath(1,120)
Better to modify the Collections and/or Find Results folder formats to include those columns, then they are there when you use the Find Panel as well, and no need to edit any other commands.
Depends on what you want to have. The code I provided is only useful if you want to only temporarily apply the changes. However, it provides a simple solution for the problem monkin describes in his first post that there is no (,)-argument for the Set COLUMNS command. This probably makes his feature request needless.
Thanks Kundal, agreed and working. Please ignore the specific feature request about columns in the very first post.
This is exactly what I meant.
I fully understand what you are saying. And I agree it is preferable (and simpler) most of the time.
However sometimes it is not -- occasionally, I would still like to create a command/string of commands along the idea of a 'macro'.
In line with the philosophy of Dopus and as stated before, for some users it is sometimes more practical/intuitive to work in this way, especially whilst in the process of learning the commands and scripting possibilities.
But most importantly, it may be the only way!
For example, few months ago (when I was completely new to Dopus and even basic scripting) I wanted to be able to r-click on a folder to create a new file WITHIN it.
Kundal's fine suggestion for text files worked only because Notepad/Emeditor apps themselves, prompt for a new file if it doesn't exist.
But I just thought of a solution, for all filetypes. (Add it to the context menu of 'All folders')
@nofilenamequoting
@firstfileonly
Filetype NEW={dlgchoose|Filetype:|Text=.txt+Word-Document=.docx+Excel-Document=.xlsx} NEWNAME="norename:{dlgstring|Filename:|}"
Copy Move "{$newfile}" TO "{filepath}"
@confirm:Open now for editing?
"{filepath}{$newfile}"
The "problem" is the fifth line written in bold, ie. ideally it shouldn't be necessary.
But it doesn't matter, so "scripting the user interface" is an acceptable solution because the command works perfectly. Please give me the choice! After all this is Dopus
Quoting the Opus manual:
Leo:
Personally I've never had this problem. Other 'macro' type programs are infinitely more inferior. This is why I chose Opus. But this could be addressed by a command modifier. How about something like
@disablemouseclick
which would disable any mouse input for entire duration of the command/button (or only respond to Esc key)
or one that would only act until the very next command, similar in idea to @runonce
Not my opinion! Is flat view also messy?
Finally, the point I would make is that Opus' strength lies in its versatility. It allows people to be inventive. That's why we have the discussion and share ideas. Often the same thing can be performed in multiple ways. This is the beauty of it.
When things do not work, we come up with alternatives ONLY if necessary,
But it is better to have many ways to experiment, than for particular users (of any knowledge level) not being able to come up with something that suits him/her.
And especially, if the features are easily implemented??
To resummarize:
Dopus to wait until the 'Find' command has finished and populated the results, then executing the next line. eg. something like this to work:
Find *.wav IN "D:\samples" CLEAR SHOWRESULTS=tab COLLNAME=TEST
Go coll://TEST
This is getting quite open ended, but at the end of the day there are sometimes good ways to do things and bad ways to do things. That is true of anything that you can script or program, not just Opus.
If you get stuck just ask at the forum and someone will usually help if there is a better way.
In general, if you've got a command which is having to create temporary files or collections and manipulate them to get the desired end result, then there is probably a better way to do it. If there isn't we'd rather put the time into providing a better way than into improving how the messy way works.
(Also, we're more likely to help with more lengthy/difficult/time-consuming questions if you link your account.)
