So... if I run the following from a lister where I've used Set LISTERTITLE=Test, I get expected behavior (OK confirmation):
@ifset:LISTERTITLE=Test
@confirm OK
@ifset:else
@confirm FAIL
...however, if from ~some other lister - I try to bring the lister titled "Test" to the front, I can't get ~other things to work the way I need. For example:
[code]go findtitle=Test
@ifset:LISTERTITLE=Test @confirm OK @ifset:else @confirm FAIL[/code]
...properly brings the lister I've titled "Test" to the front, but the @ifset check fails (FAIL confirmation), presumably because it's still running in the context of the lister where I ran the button from, instead of the lister that got brought to the front because of the go findtitle=Test command.
So naturally, I then try to use the embedded command system...
go findtitle=Test
[
@ifset:LISTERTITLE=Test
@confirm OK
@ifset:else
@confirm FAIL
]
...but when I try this, none of the @ifset stuff appears to run at all - i.e. I don't get either of the @confirm dialogs.
I'm guessing that the embedded commands don't operate on a go command with FINDTITLE in the command? If so, can the embedded commands system please be extended to operate on listers called to the front with Go FINDTITLE?
The use case here is to be able to use a single button to RE-USE a purpose-built lister with a specific TITLE if it's already open, and if it's not open... to go ahead and open a new lister with the desired title and other settings.
So... this is a feature request, so I hope the use-case driving the "why" is clear.
Obviously you'd know far better than I the ins and outs of how this works or doesn't work, and to be sure - testing ~other @ modifiers inside embedded commands also seem to do nothing such as you've said. So thanks for explaining, and I'll now ask the following:
1.) can @ modifiers be made to work inside embedded commands...? Only a few of them would seem to even really make sense, such as @ifset, @ifpath, maybe a few others.
2.) though you're right about the @ modifiers not working in embedded commands, it seems what I originally thought caused it not to work ALSO doesn't work... for example:
go findtitle=Test
[
set view=tiles
]
...results in nothing happening, when you should expect it to set the view mode in the lister brought to the front to tiles; which works fine if you swap the "findtitle=Test" for a simple "new". So can this ALSO be made to work?
I doubt embedded commands work at all with Go FINDTITLE, since they're only implemented for a few special cases (e.g. opening a new window, not finding an old window).
Well... yeah, that's what I said ... they don't work with Go FINDTITLE - hence the feature request(s)?
For the other bit - did you mean going back to using dopusrt tricks to smooth out the ~timing issues of where commands get run? If so, that's often enough of a kludge that I'd probably resort to seeing if I could use autohotkey for what I want instead.
Actually I'm not sure this would work that well. Go FINDTITLE can potentially find more than one Lister, so what would happen in that case? Run the command in all of them?
Hey there Jon... true, but only one of them will be actually be brought into input focus... I just opened 5 listers, cascaded 4 of them, and one I left maximized... and from the maximized lister I ran 'Go FINDTITLE=Test'. While all 4 of the cascaded windows were brought in front of the maximized lister, obviously only 1 can get input focus, which was evident when I just started typing and the one "on top" started responding in the FAYT field.
Now, I realize that such a thing will make it impossible to have predictability if you have multiple listers with the same title, and you specifically need or want only ONE of them. But then, regardless of what I'm asking for - 'Go FINDTITLE' isn't necessarily the tool for the job if you're going to have multiple listers open with the same title - though it'd help at least bring the several listers to the foreground.
But the reason for my request here is actually to make it so that I only ever have ONE of these listers open; to re-use it if it IS already open, and to launch a new one if one is NOT open. For example, I've got 3 or 4 uses-cases for this where each of them would run some variation of:
Go FINDTITLE=Test
[
@ifset:LISTERTITLE=Test
Set SOURCE
@ifset:else
user_command {s}
]
..one thing that I just realized though, notice that in the else case I'm running a user command. If that user command itself were to contain something like:
Go &PATH& NEW=0,0,800,528
[
Set SOURCE
Set LISTERTITLE=Test
other_embedded_stuff
]
...would you envision that causing any trouble? I'm asking because I'd be calling the user command from within an embedded command block, that hasn't necessarily ~completed yet before the user command starts following it's own series of embedded commands. Also asking in advance to be transparent with you, because I'd hate for you to consider what I'm asking for, implement it, and THEN find out the additional details of my use-case need yet more work to actually work smoothly ...
I think the embedded user command with its own embedded function will work OK.
Just make sure the user command's embedded function doesn't invoke the same user command
Thanks alot Jon! Since my use-case is to have only a single lister with the TITLE I'm looking for, I don't have an opinion on the embedded commands running against all matching listers one way or another .
Since I can't test it yet, can you say - if NO listers with the specified FINDTITLE are found... will the embedded commands still run in the current lister? I'd need them to...
Also, do you have any feedback on Leo's explanation of @ modifiers not working inside embedded commands? By "feedback" I mean - if it would be feasible to change so that @ifset (maybe @ifpath as well) could work inside embedded commands? Given the current behavior, instead of running all the @ifset stuff I need to run in the embedded command block itself, I broke it all into a user command which I then run inside the block (of a Go NEW command). I seem to get the behavior I want... but I can't think through things far enough at the moment to wonder if having to do so will cause me any trouble or not. As long as I can expect the change to Go FINDTITLE to work the same as a Go NEW in this respect, then I'll probably get what I need by forklifting the @ stuff into user commands - but, any thoughts on that?
No, if the lister title isn't matched then the commands won't run.
I think @ifset etc should work ok inside embedded functions although I haven't tried it.
Damn, then the changes to Go FINDTITLE and embedded commands won't help me ... unless you could make it an advanced option or something to allow continuation of the embedded command block if no matches are found (I otherwise kind of understand the logic of NOT continuing if FINDTITLE gets no match). Otherwise, I'll have to resort to autohotkey or something...
Leo had the right of it re @ modifiers inside embedded commands though - they don't run. But it seems I can break what I need into user commands to workaround it if it can't be changed.
Well that'd be great - thanks alot for that Jon... greatly appreciated.
About the @ modifiers in embedded commands. Hmm... I guess I kept testing specifically with FINDTITLE. But now since we've confirmed the FINDTITLE option didn't allow embedded commands - yeah, it does appear that they're working with a regular Go NEW command - though similar to another thread where Leo found there is a need to set the new window as SOURCE in order for a Find command to operate in the new window instead of the original lister where the code was run, you also need to do so in a few @ cases. But now I know - so... Great!
Thanks alot for the changes around this in 10.5.0.5 Jon...!!! Combined with various other features (some of which have been added ~fairly recently in the 10.x releases) I've been able to make good on several of my use-cases with this. At a high level, for anyone interested:
As I may have mentioned - my main use case(s) for this have to do with the desire to further pursue my idea of "purpose built" lister ~layouts. I've long used various Layouts (in favor of other similar methods such as Styles, or buttons to load saved folder formats and tab groups, etc) for specific purposes such as: ~managing music, vs just browsing album folders via thumbnails view... ~managing and modifying images, vs just viewing pictures in large thumbnails before slide-showing... several other project specific layouts, and yes......... even the hotly debated separate, detached, floating, whatever - Find window .
There are indeed OTHER WAYS to do go about doing the ~sort of things I want to do in some of these use-cases - but none of those other ways achieve quite the same effect, and generally need some additional clicking and buttons, etc. In most all of these use-cases, a common characteristic in how I prefer to work is to have only a single ~special purpose lister open for doing the ~work, and other listers open for navigating around and looking at things to ~work on. That innocuous description is a good example of there being OTHER WAYS to get someplace similar, for example - I lobbied for tabs back in 8.x, and I've used them heavily for years... but there are still times when I prefer to work between multiple listers. Particularly when I'm connected to multiple monitors...
At any rate - some of my explanation may seem a bit obtuse... here are some of the ways that I'm playing around with this new capability - with a common desire being to RE-USE a single instance of one of the "purpose built" listers I'm using for some specific type of work:
[ul][li]Modifying the Left double-click + Ctrl Event for the All Folders filetype to include @ifpath checks that determine how to handle things a bit differently depending on where I am. I.e., if I'm in a certain music related folder path and view-mode is set to details - then Ctrl+Dbl-click on a folder will launch or re-use an existing "Music" ~layout set to completely different TOOLBARS, view-mode, specific view settings, tree/notree, etc... This general idea is something I'm applying to 4 different scenarios.[/li][/ul]
[ul][li]A single hotkey I configure in a variety of other applications to run an Opus user command that will load or recall a specific Opus lister title (so that I don't get too many of these listers open) that opens new or findexisting tabs to folder paths related to the app that was active when I ran the hotkey. Though I won't ~regularly use this... every so often I update enough apps and related configs at once that I spend a good few solid hours tweaking around those apps. Again, not something I'll use too often - but WHEN I do, I'll use it for several hours at a clip to just make things easier. So this is now Opus helping to make my customization antics in ~other apps easier...[/li][/ul]
[ul][li]An idea that really got me going on this request - since I was already using layouts to achieve a similar result as the first bullet... was that when I am doing certain types of work in one of the types of specialty listers above - and need to find content to do related work on... I'm going to likely want access to certain toolbars and buttons to then do specific ~stuff with my find results, where that ~stuff will defer depending on the work I'm doing in the first place. Not a big deal to just load toolbars as needed - but as I was already looking to refine some ways I've tried to get a satisfactory separate Find window - I figured - why not use this new ability to call up or recall a ~single Find window if one is already open - and load up a specific toolbar related to the work I'm doing in one of my ~specialty listers (based on it's title). I've fussed a bit with this so far and am liking it, not to mention this enhancement gives me a bit better handling for my use of a separate find window, as previous methods had me opening lots of find windows to the point I had switched back to the in-lister find panel a few times - lol. I'll share my results with just a regular detached find window without my other mods here on the forums in another topic...[/li][/ul]
... they don't work with Go FINDTITLE - hence the feature request(s)?
...
... unless you could make it an advanced option or something to allow continuation of the embedded command block if no matches are found (I otherwise kind of understand the logic of NOT continuing if FINDTITLE gets no match). Otherwise, I'll have to resort to autohotkey or something...
.