Perfectly understandable. And thanks for the quick response.  :)

And of course what I present here are just my opinions, as much as I personally may think they're valid and correct one.

3. If the regex engine you're using doesn't support something like this, then of course not much you can do. But generally most (all?) user tools for search&replace that I can quickly think of (and regex code/development libraries) allow something like a "fake" backreference to the full match. Usually (in my experience) that's done by something like $0 or \0 (e.g. a capturing group for everything before the first actual capturing group) for tools that otherwise use $n or \n , . It's mostly a convenience thing, so not strictly necessary, but it's a very common one ("why do I explicitly need to indicate the group boundaries when this group is already very clearly defined, and is already a known individual entity to the engine?"). Though, again, yes, if it's not something that your regex engine handles, then it's technically correct, so this does downgrades to feature-request rather than bug.

4. Oh, I like that as a feature, for sure. But I think it should be done only if the user explicitly wants to use it, otherwise it should just be assumed.
If the user didn't explicitly provide the location, then it shouldn't match anything on the input regex. If working on "file.ext" in the current directory then it's called "file.ext", not ".\file.ext". If the user wants to move it somewhere then they don't replace .\(.*) with c:\somewhere\$1 , but rather (.*) with c:\somewhere\$1 . This should carry fine to sub-folders of the current folder.
If not using the current folder (or using sub-folders in the pattern) then the user needs to specify the path explicitly anyway, so no problems there. The ".\" should be a valid destination location (I didn't check if it is now), but shouldn't be matching on the input unless explicitly put there by the user.

5. Since it's posted here as a windows tool, file extensions are very much a separate part of a file name, both for the O/S and for the expectations of the very large majority of users. Files with ".tar.gz" are handled by programs that know how to open ".gz" files, which hopefully also know to notice that the base name ends with ".tar" and what it means (which for practical purposes I think anything that handles ".gz" is aware of). But as far as the O/S is concerned, when making file associations/icons/filters, that file has a ".gz" extension. And file renaming can often includes the desire to change the file name without touching the extension.

Hi,

I know I'm reviving a really old thread here, but since it does contain the background I figured it will be better than starting over.

Basically I came up the same problem, I've started to test Desktops, and have the same issue with FARR opening its window on the original first desktop rather than the active ones.

But... Looking a bit at the relevant APIs and documentation, I think that handling this is fairly straight-forward, and depending on what FARR does behind the scenes might even be very quick and easy.

So, some additional details that were missed in the original discussion: True, there is no way to transfer windows between desktops. But, and it's a big but, there is no problem creating new windows, from new threads, on different desktops.
Once an application thread interacted with the UI it's locked to a desktop. But a new thread, on the same application, can work with other desktops (such as the "currently active" one) without a problem.

The cost on the program is to have a different UI thread for different desktops. Which depending on how the existing code goes would mean either creating a new UI thread any time the window is shown, or instead just creating new duplicate threads for different desktops and keeping that pool.

For example, basic C code with WIN32 API that creates a message-box on whatever the currently active desktop is. Calling this from within the thread procedure, before the thread interacts with any windows, creates the messagebox on the active desktop instead of the one originally used by the application:


Any chance of you considering making such a change in the foreseeable future? I really do like the behavior of Desktops compared to the other (hide/show windows) programs of the type, but using FARR with it currently is very clunky.

I agree with you all the way and have added your idea to the wishlist.

Thank you.

A better alternative is to be able to say "this application *and* any of these (partial) window titles". It would provide for better fine-tuning of the filters.

I agree.

I think that the potential disadvantage here (if someone does want to block storing from the same source for multiple different programs then they'll need to define it multiple times in the filter) is better than the, probably much more likely, alternative of a risk of matching also unwanted and unexpected windows.