// Other variation of @keydown modifiers here removed for example
// Using /temp in examples for whoever tests it
@nodeselect
@keydown:ctrl
Go "/temp" OPENINDUAL=vert NEWTAB=findexisting
Set DUALSIZE 65
Copy CREATEFOLDER="{date|yyyyMMdd}{time|HHmmss}_{file$}" ARCHIVE=.7z,keepfolder TO="/temp"
This one works if the Copy command is first (compared to above)
@nodeselect
@keydown:ctrl
Copy CREATEFOLDER="{date|yyyyMMdd}{time|HHmmss}_{file$}" ARCHIVE=.7z,keepfolder TO="/temp"
Go "/temp" OPENINDUAL=vert NEWTAB=findexisting
Set DUALSIZE 65
This works too
@nodeselect
Go "/temp" OPENINDUAL=vert NEWTAB=findexisting
Set DUALSIZE 65
Copy CREATEFOLDER="{date|yyyyMMdd}{time|HHmmss}_{file$}" ARCHIVE=.7z,keepfolder TO="/temp"
Seems that @keydown is causing a problem. I'd prefer to use the first one . Shouldn't all 3 examples work regardless of the command order?
What’s it copying/zipping? The copy line isn’t specifying what gets copied, so it’ll copy the selected items, but if you’ve just changed folder (on the first line) there won’t normally be any selection.
Neither of them are really correct code, even if it works sometimes. If you change folders there’s no longer a selection. Do the copy first, then change folders.
(When it works, you were probably just getting lucky with the timing of things, or some other detail that it’s best not to rely on as it won’t always be true.)
I now see that when opening the dual display what was once the source tab becomes the destination tab so I can see that being a problem as to why it doesn't work. Isn't there a way to open a dual display while keeping the source the source? I can't look into it now have to go to work! Will check later. Thanks
I'm not changing folder I'm opening another folder in dual-display. The folder and selection prior to clicking the button remains the same after clicking the button since I have @nodeselect included in the button function.
I found that running the below command while holding control swaps the source and destination. What was the source becomes the destination after clicking the button.
Go "/temp" OPENINDUAL=vert NEWTAB=findexisting
This is what is causing the 1st example in my OP to fail (since it's using @keydown:ctrl and control swaps src and dest). At that point the source is the newly opened tab and yes nothing is selected in that tab because it was just opened. The Copy command is looking for what is selected in the source.
If I switch @keydown:ctrl to @keydown:shift then the 1st example in my OP works.
Try this and see if you experience the same thing I do.
Close any dual-displays so you are in single-display
Run the Go command above in a button without holding control
Left side is source right side is destination
Close the destination (right side) returning to single-display lister
Hold control and click the Go command button again
@Leo
Did you even bother testing any of the example functions in my first post or did you just skim through and make assumptions? I suspect the latter considering your statement of "If you change folders there’s no longer a selection". Which is not even happening in the function.
Lucky timing? The timing is irrelevant so long as the source selection remains the source selection when the Copy command runs (which is not the case with example 1 in OP as pointed out above with control key). In addition, the Copy command explicitly defines where the file will go with TO= so therefore doesn't rely on the destination tab. That would mean opening another tab in dual-display would also be irrelevant. Again, so long as the original source tab remains the source tab with the selection.
I'm seeking bug free software especially now that I pay for it annually. I guesstimate I've reported around 60-75 (or more) bugs since I've joined this forum. You'd think that would mean something by now. Or maybe upon seeing one of my new threads eyes roll. I don't create the bugs I just report them.
Maybe you should re-apply the bug-report tag you hastily removed since your assumptions are incorrect. Unless of course it's the case of "I can't reproduce that here".
Take no offense to this post and have a great day.
FWIW, it is working here, both with files, folders, one item or multiple items selected.
Using 13.23.9
--
EDIT: I do get different results though depending on the current lister status regarding opened panes:
Case 1: Lister is already dual pane. Then this works ok. The source selection gets into an archive in /temp named after the first selected file (+ timestamp)
Case 2: Lister is single pane. This time, it seems the OPENINDUAL shifts focus to the tab opened in the destination pane (making it the source pane). In this case, I get an archive from what is selected by default.
Note that there might be a setting that auto-selects (or not) something when opening new tab/folder. So if your setting is to have nothing selected, in that case, that would mean no selection = no archive created.
I think it'd be best to have these multiline commands act first on what is selected before acting on the way the lister is built (adding/removing panes, modifying layout, opening new tabs, ...), as this can lead to unpredictable situations depending on the timing everything happens.
--
EDIT2:
You may want to try to modify your first non working button code by adding a nofocus to the NEWTAB option:
// Other variation of @keydown modifiers here removed for example
// Using /temp in examples for whoever tests it
@nodeselect
@keydown:ctrl
Go "/temp" OPENINDUAL=vert NEWTAB=findexisting,nofocus
Set DUALSIZE 65
Copy CREATEFOLDER="{date|yyyyMMdd}{time|HHmmss}_{file$}" ARCHIVE=.7z,keepfolder TO="/temp"
That change, at least here, makes the use case 2 above work as use case 1.
Adding nofocus did the trick while holding the control key. But when not holding control key it works fine without nofocus. That begs the question why holding control needs nofocus and the other doesn't.
Correct. Although I didn't specifically point out that detail, I had it part of the steps to test with Go command above.
Close any dual-displays so you are in single-display
Run the Go command above in a button without holding control
Left side is source right side is destination
Close the destination (right side) returning to single-display lister
Hold control and click the Go command button again
I can not answer that one but only suspect that it's somewhat related to the way everything works behind the scene. I would say that this refers to my suggestion about the order one puts up the multilne commands: the more you enter actions, the higher the risk of things getting unpredictable.
Adding the @keydown:ctrl adds up to the way that multilne command is parsed and interpreted.
I admit I didn't see that. I was focusing on the first post and after my first answer, since it was bothering me not to have the same behaviorur at all (compared to your description), I just thought this could be a factor influencing the end result.
When the Go command (without nofocus) is the only thing in the button function and without the @keydown:ctrl modifier. The source and destination are still swapped while holding control.
The default behaviour of the Set DUAL command changes when the Ctrl key is held down (technically, what it does is toggle the state of the Preferences / File Displays / Options / Set new panel to source when switching to dual file display option).
Normally doesn't cause a problem but interacts with @keydown as you've discovered. We'll add a fix for it in the next beta after the 13.24 release (i.e. 13.24.1).
If you always want to copy under /temp, include TO /temp in the copy command. It's probably also best to run the copy command before opening the new tab instead of after.
I am using TO in the Copy command and /temp folder is used in this thread example only (not my actual button) so whoever tested it would be working with an existing directory.
but only suspect that it's somewhat related to the way everything works behind the scene. I would say that this refers to my suggestion about the order one puts up the multilne commands: the more you enter actions, the higher the risk of things getting unpredictable.