GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Command: SelectEx (extended Select command)



The filter-idea is tempting and might even boost performance, but I don't see this coming within the next couple of weeks.
It would "just" allow a different way of getting the same results, so priority is not that high I'd assume?! o)

Would the filter editor be ok? o)


There's no rush. For my personal needs everything is fine as it is now.


Yep, but a mix of radio-buttons and pulldowns would be better :slight_smile:.

Unfortunately I have no time until middle of next week to design a functional layout (and an icon), which I think is necessary before programming a GUI. But if you can wait...


You sound like I would be eager to do that GUI-thing, I'm actually not! o) Though admittedly, it's interesting as an experiment! o)
If you could provide some basic *.html or a *.xaml representation of a finished layout.. I'd consider putting it into working condition as an HTA (hypertext application) or powershell driven .Net-GUI.


Oh wow that's some serious amount of (quite nice) code (over 1600 lines, 125 KB in current latest version)! :astonished:
And a very powerful add-on indeed! :thumbsup:


Updated to v0.4.3:

  • MAKEVISIBLE fixed, threw error in previous upload
  • JSBREAK finetuning: return true to stop item picking, false to skip item and null/undefined will select/pick
  • JSFILTER performance gain
  • Usage of Confighelper v1.2 and XLog 0.3

@jsys -> Thanks thanks! o)
Actually it's around 60kb, but it comes in UTF16 because the upload preparation of ScriptWizard requires that.
Not an issue I guess, but if size matters for anyone, the well known TurboImploder might also work for DO add-ins. o))


I tested your exact config-line and path and it works here, do you use the latest SelectEx version?

What kind of saved selection are you talking about? Selections stored to memory or to file?
Actually both of them should survive a DO restart, but maybe you can share some more details and we find what's going on. o)


It's version 0.4.3, which should be the newest one. Maybe i made a mistake, by just appending some lines at the bottom, like here:

;you can use ; or // or # to comment out lines
;syntax is: [REGEX=]<path> => [REGEX=]<item name>

;standard path (select program files)
C:\ => Program Files

;alias for path and regex for item
/home => REGEX=dopus.exe|dopusrt.exe

;env-var in path and regex for item (all log files)
%windir% => REGEX=.+\.log$

;using regex for the path
REGEX=.*\\drivers\\etc => hosts

*\Directory Opus => dopus.exe
*\Outlook => Outlook.pst
C:\Passwords => File4.txt
C:\Program Files\Light Alloy => LA.exe

So maybe it has to be applied in another way? The red lines represent your example part, the green ones are those i've added.

For example, i select some random files for a test, then choose "save selection to" -> example.txt, then "load selection from" (the same .txt file), but nothing happens.


Ok, i have better results now with the "store to memory" option, which loads the files fine even after a restart. Interesting feature. But the selection will be lost, only if i change the file display once, and change back.


Funny, but now it works, after i restarted Opus. And i did not forget to set the "autoselect" option to "true", when i tried first. :smiley:
Anyway, i have to play around now a bit with this very useful script tool set.


tbone, i'm playing around with both scripts (Leo's and yours), and i have a suggestion for your version of the "autoselect" part. If i use the option "automatically select first file in folder" in my Opus settings, which i do, i will end up having two selected items, if i use the script to point at a certain folder. Therefore i would suggest, that you include some sort of "select none", before your script selects the given item, overriding the "first file" selection.


Updated to v0.4.4

  • TOFILE/FROMFILE encoding-awareness added (did not always load selection-files correctly)
    SelectEx will detect unsupported encodings now (that is UTF8 and UTF16-BE) and suggest converting the files.
  • new script config "AutoSelect.DeselectNoMatch" to deselect automatically selected first file


  1. I was able to reproduce the FROMFILE feature not working in all conditions, maybe you like to try again. Make sure the selection-files you try to load are ANSI or UTF16-LE (UNICODE) encoded if they were not created by SelectEx. You can use notepad.exe to convert files that do not meet this requirement.

  2. Suggestion implemented

  3. You mean the red lines are those you added, right? o))
    This won't work, as currently there is no support for wildcards: *\Directory Opus => dopus.exe
    But you can use regex, which should be more versatile, like this: REGEX=.*\\Directory Opus => dopus.exe


Updated to v0.4.5:

  • the AUTO feature, to trigger auto-selection from commandline (same as AutoSelect when entering a folder), is now independent from the "AutoSelect" script configs (despite the list). That means you can disable AutoSelect and still use it occasionally from a "SelectEx AUTO" button. The script configs "AutoSelect.MakeVisible" and "AutoSelect.DeselectNoMatch" also don't apply anymore if AUTO is invoked from a button or commandline (use the regular MAKEVISIBLE and DESELECTNOMATCH switches if desired).


I'm seriously afraid, you can fix bugs faster, than i possibly could find them :blush: . I find all of this a bit ludicrous, yet delighting. Opus is pretty much like the "rome" thing ... there's a thousand ways to it ... :grin:


Indeed there are! o) If there's still something left I can do, let me know! o)

Btw: The new AutoSelect.DeselectNoMatch feature comes with a condition for you, the next time you encounter problems, please report asap right here - in the interests of all of us - and to raise general satisfaction, deal? o)


:thumbsup: Congratulations @tbone on a fine piece of work.

Regards, AB


One suggestion for the Autoselect part: Maybe the existing autoselect paths could be backed up in some other place, so if we update script versions, we could retrieve them from there. At the moment, each new version starts empty, having only the default examples.


As long as the script's filename is unchanged, any settings should remain.
Did you rename or alter the script's filename after/before updating?


Hmm, that could be the reason, indeed. I'm not aware, which change i made recently to the older version, but i don't recall having had that replace dialog last time, when i updated. Which indicates, that you must be right. Thanks again!


Good! o) Btw, this is why I once suggested that DO should rely on a script-internal identifier, instead of the scripts filename to identify scripts and their settings. I guess many users are not aware, that they screw their (script) configurations and existing column setups if they rename scripts that were already in use. Regarding v11.5.1