Hi, when I click on a group header, it selects all the files in that group, however, if I then click Enter, it collapses the group, when I would expect it to open all the selected files. Is it possible for this behaviour to be implemented, perhaps by using the spacebar to expand/collapse a group but using the Enter key to open the selected files, like in Explorer? Maybe an option to choose what keys do what on group headers?
Thanks for your consideration.
Explorer doesn't seem to behave like that, either in Windows 7 or 8. Clicking on a group header and then pressing Enter does nothing from what I can see.
It seems dangerous to me to implement this functionality - you could very easily end up opening a huge number of files accidentally.
In Explorer, pressing enter with a bunch of items selected, opens the items. That is standard behaviour.
Yes, and Opus does that too. However you were asking about pressing enter after clicking a group header, and in Explorer that seems to do nothing.
Okay then, if I single-click on a group header it automatically selects all the items in the group, but the focus remains on the group header. I can run toolbar operations on the selected items, or drag them etc. But I can't launch them?
Seems illogical...
The objection, that users could accidently open hundreds of files is valid, ending up with hundreds of instances of a program. Maybe it should be possible only per using the context menu,
which would help to prevent happening that.
The point is that it appears the files are selected, and they behave as such for most keyboard operations, e.g. delete. I really think that the standard Enter key operation should work here too. If there is a concern over launching multiple files, perhaps a prompt should appear (optional, please) when more than a certain number of files are selected?
Thanks for reading again,
Chris.
I should mention this is on my work laptop running version:
Directory Opus Pro 10.5.4.0 (5080) x64
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"
I think Jons first point was simply to counter your statement that what you want is how Explorer behaves, which is not the case - on my system Explorer doesn't do anything on , not even collapse/expand the group.
Your observation that you can drag and drop the files under the selected group header isn't really supportive because you're then explicitly clicking on one of those ~selected files to do the D-n-D operation, switching focus to those files instead of focus remaining on the group header anymore. Similarly, I guess clicking a toolbar button that wants to do somethign with files wouldn't do anything useful to a selected group header, so it goes ahead and operates on the selected files. But you've got a good argument that the same concern about launching hundreds of files applies to a toolbar click scenario as well maybe, but I think the fact that it behaves this way actually helps you...
For instance, instead of 'Enter'... maybe theres some other way to do what you want in a way that you'll still find agreeable?
As an example - you could define your own hotkey (lets say Ctrl + Alt + Enter) and set it to run ContextMenu VERB=open. In a quick test here it worked ok...
I understand the points made, I just don't understand why other keys work on the selected files, and not the Enter key.
2 examples:
Click a group header, all files of that group become selected, click delete --> files are deleted. (I can also do other things like cut/paste etc.)
Click a group header, all files of that group become selected, click Enter --> the group collapses, why, when hitting the Enter key, do the files not get opened?
The main issue is not about the Enter key acting on the group header in Explorer or in Opus, it's about the Enter key not acting on the selected files, when the files have been selected by clicking on the group header.
When navigating using the keyboard, if I select a group header, I can click space/ctrl+space to select or deselect the files in that group, I can click the left or right arrows to collapse/expand the group. I just don't understand why the use of the Enter takes the focus off the files and acts on the group header.
I love Opus and if you can't do anything about it I'll still be a very happy user.
Many thanks.
If you click the group header, then use Ctrl+Down Arrow to give focus to the first item below it (without deselecting the others), then you can push Enter to open all the items.
This is consistent with Explorer. For the Enter key to launch things, a file or folder (not a group, nor any other part of the user interface) must have the focus.
You can also right-click the group header and choose Open, as in Explorer.
The difference with Delete and Enter is also consistent with Explorer.
Essentially, Enter has a different meaning when the focus is on a group header to when it is on a file or a folder. Other keys don't. This is standard behaviour and what people will expect coming from both Explorer and previous versions of Opus. Turning something which people expect to expand a group into something that potentially opens hundreds of files seems like a bad idea.
Thank you for the explanation, would you possibly consider adding an option to change the behaviour?
Thanks again, cheers!
If more people request it then we'll consider it.
There are plenty of alternatives, mentioned above, to achieve the same result though.
Now that the 'focus' vs' selection' state was clarified by Leo - I'd also think it's obvious that none of the other actions that ARE operating on the selected files (delete, etc) carry the same risk as hitting would. Thought - TBH and back to your point, I don't think many ppl would be too happy at unintentionally deleting hundreds or thousands of files 
.
In any case, I don't think the discrepancy in behavior between vs other keys is "accidental"... I think it's entirely intentional for the reason mentioned 
.
Out of curiosity, whether or not GPSoft add an option for what you want... why not consider binding your own hotkey to run the command I mentioned. I realize its an extra thumb you'll need to hold down a qualifier key, but it's probably better than a context menu, toolbar button, or first hitting some other key combo ~before then hitting (i.e. what Leo said about using Ctrl+Down arrow).
By the way... good thing Explorer lets you right click on an pplications footprint on the taskbar and do a "Close all windows"... otherwise I'd have been a little miffed at Opus when my test to see if this would work for you opened up 134 new folder windows... 
.
Quick note... this might have some unintended consequences, but I just tested actually running the command I mentioned above by manually binding just plain as the hotkey... and it looks like this circumvents th normal Opus behavior! So you may have the makings of what you want right there.
THAT SAID: I also just realized that running ContextMenu VERB=open actually isn't the right thing to do as "open" isn't always the 'default' verb or action for every filetype. In fact, when I ran the previous command against a bunch of folders, I failed to realize that what happened was that tons of Explorer windows are what opened... The FileType ACTION=dblclk command might be more appropriate (though if the items selected are folders, this results in Opus reading each of those folders in series in the same lister and same folder tab - rather than opening separate tabs or listers for each folder).
Jon/Leo - do you think there would be any significant unexpected results from re-mapping just the unqualified key...?
I created a simple button which runs {filepath$}, and mapped it to Enter, it opens all selected files when hit, or the first of any directories selected. Haven't come across any negative side effects yet, the address bar still works, as does the command popup.
Does anyone know if there's a way to suppress the "File Function" dialog?
Cheers everyone!
Edit: never mind, I increased the Delayed Progress Indicators value to 3000ms.
Increasing the progress delay to such a high value will make everything else behave in an unwanted way since now no progress dialogs will appear until an operation has taken at least 3 seconds.
Why use {filepath$} instead of the command steje suggested ( FileType ACTION=dblclk )?
[quote="crtrubshaw"]I created a simple button which runs {filepath$}, and mapped it to Enter
...
Cheers everyone![/quote]
You're welcome 
Thanks 