By the way, I think that there will be also an error occuring when in the last folder if some files are present after this last folder.
DOpus will try to browse as a dir and shows an error message. Is there a workaround for that?
You could work around it by passing the selected file path {f} to something which checked whether or not it was a directory. e.g. A short VBScript.
I was sure I had to go once again through vbscript 
Still, I don't understand why the folders aren't remembered when going up.
I tried with the option I told in the previous message, and I also found other options to select folder/file on their own when going to a folder, but nothing seems to change the problem. I always get to the second folder of the lister.
Any idea?
I don't know why it's happening but it doesn't seem worth investigating when it only affects the user-command version and it's such a simple command that it doesn't really need to be a user command, TBH.
Using dopusrt to run the 2nd and 3rd lines in the user-command might fix it. Perhaps the selection is being done at the wrong time.
Oh wait, the problem is you're using Go UP and not Go BACK UP
Go UP on its own won't select anything. It reads a brand-new copy of the parent folder. You need to use Go BACK UP to make Opus use the cached parent folder (with the remembered folder selection).
thanks, this works great!
Also, when using the command on the folder extremities, it doesn't display an error, it just goes UP and stay at this place, which is nice indeed, no need of a vbscript for that
For some reason this code very often doesn't switch to next folder. Sometimes it works ok but very frequently it just refreshes the current folder view. Any idea as to how make it work more reliably?
GO UP BACK
SELECT NEXT
GO {f}
I copied your script and replaced GO UP BACK to GO BACK UP (Leo's) comment above, and it works for me.
The order of the arguments shouldn't matter.
I don't think the order of params makes any difference in this case but I tried to change to GO BACK UP anyway - no result. It works in about 60 - 70% cases. Eg. I went to "c:\program files\AVAST software" (witch is the first file in program files) and wanted to go through all folders in "c:\program files" (there are 59 of them), clicking the button. It took me 95 clicks on the button. Sometimes I needed to click 3 - 4 times for one switch. I didn't click very quickly, every time I waited for folder content to load. I'm using list view, but on details mode the same happens to me.
It looks like "select next" is [very often] triggered before the content of parent folder is loaded so the command actually does nothing.
[quote]I don't think the order of params makes any difference in this case but I tried to change to GO BACK UP anyway - no result. It works in about 60 - 70% cases. Eg. I went to "c:\program files\AVAST software" (witch is the first file in program files) and wanted to go through all folders in "c:\program files" (there are 59 of them), clicking the button. It took me 95 clicks on the button. Sometimes I needed to click 3 - 4 times for one switch. I didn't click very quickly, every time I waited for folder content to load. I'm using list view, but on details mode the same happens to me.
It looks like "select next" is [very often] triggered before the content of parent folder is loaded so the command actually does nothing.[/quote]This technique of navigating through directories was useful for me, but now I'm experiencing the exact same problem
This technique of navigating through directories was very useful for me but now I'm experiencing the exact problem as described above. Has anyone figured out how to make this work correctly and more reliably?
I´d expect this simple code to work. It´s supposed to abbreviate the action of looking through various subsequent folders.
It shortly jumps to the next folder (so "Go Up" / "Select Next" works), but then immediately falls back to the starting folder.
What is wrong with that code? 
Go UP
Select Next
Go {f}
Existing thread about that: [the threads have now been merged].
Nobody has posted a reliable method, though.
EDIT 2018: Here's one - Command: Go-Relative (go to next/prev sibling folder)
When you Go UP the folder is re-read and the selection will be on the top item in the list. If you use Go BACK then the selection will remain where it was and so Select NEXT will have the desired effect. I'm not sure if it will actually work though but it's worth a try 
You'd want Preferences / Folders / Folder Behaviour / Select previous folder when going Up turned on, I expect. Then you can use Go UP or Go UP BACK, but there are probably still potential timing issues as the commands aren't designed to do this kind of thing.
I tried it, but to no avail. Seems to be a timing issue (maybe we need some delaying command like "pause 100" or something 
). I also tried Leo´s suggestion, but that folder
behavior option is already set to go "back". By the way, I have already some makro for that (an application) folder hopping, but it would be cool to have it directly in Opus.
Could you share additional information about your macro if it actually works?
I've merged the two threads together to keep all the information in one place.
Sure. I´m using Hot Keyboard Pro, which, in this case, basically records all keystrokes needed to
achieve that goal, using my own Opus based hotkeys, like ctrl-up (for GO UP), arrow down & enter.
I set the macro to only affect Opus processes, so that the triggering hotkey for HKP will only work on Opus windowses.
Also, i tweaked the speed for the macro to have optimum results.
New solution.
Your method with down arrow won't always work as some people might use big icons or thumbnails. And you have to remember to have focus set to lister. It won't work when folder tree has focus. And you have to keep an eye on what you are doing as your simple script might run an application after last folder was reached.
Here is my Autohotkey code that does the thing and works pretty reliable.
It also loops when the last folder is reached.
And it also works when folder contains files.
path=dopusrt.exe
direction=%1%
delay=%2%
if (!direction)
direction=next
if (!delay)
delay=100
clipboard=
RunWait, %path% /cmd SET FOCUS SOURCE
RunWait, %path% /cmd GO BACK UP
Sleep, %delay%
RunWait, %path% /cmd SELECT TYPE=dirs %direction%
RunWait, %path% /cmd Clipboard COPYNAMES
ClipWait, 1
If (!ErrorLevel)
RunWait, %path% /cmd GO "%clipboard%"
And button codes to use it:
Set Focus=source
cd /home
"D:\change_dir.exe" next 50
Change "next" to "prev" to navigate backward.
The second parameter - 50 defines delay between Go Back Up and Select Next. This delay is essential for the script to work properly as this is where the original button code failed.
You can try setting it to lower value for the script to work faster. But it may result in less reliability. For me 50 (ms) works great so far.
I attached compiled script ready to use.
change_dir.zip (372 KB)