Page 1 of 2

Regex search setting

Posted: 2016 Apr 07, 08:09
by aml
Regex search, e.g. for filtering, is possible by setting the 100 per cent to 0 per cent. Within a session, it stays at 0 per cent. From 1 session to the next though, it is unpredictable if the setting reverts to 100 per cent (default) or if it stays at 0 per cent. Is there a registry setting or other which I could tweak in order for the 0 per cent being persistent betweens sessions?

Re: Regex search setting

Posted: 2016 Apr 07, 10:36
by nikos
this setting reflects whatever you've searched for last. If you are saving settings on exit, it should stick. However, keep in mind, that if you have it set to 0 then type in something that isn't a regexp, xplorer2 automatically turns it off, for performance reasons

Re: Regex search setting

Posted: 2016 Apr 07, 11:31
by aml
Thank you very much for the info. I'll try to check what could cause a reset to default. When I shut down x2, then reopen it, then check by Alt-h, not only the "0" is preserved, but also the very last filter string, and then filtering works fine. Thus, I'll try to identify why sometimes the "0" is reset to "100" (up to now, I used the filtering by an external macro program, so I don't know - didn't pay attention - if the last filter string (always regex) is preserved* when the "0" is not but reset to "100"; I ONLY use x2 this way, so no-regex searches/filtering should NOT interfere). Will post again when got more info on this (e.g. when regex string is preserved but "0" is not). Thank you again!

* = for doing this, BEFORE running my usual macros, I'll check by hand first (Alt-h), on each new session

Re: Regex search setting

Posted: 2016 Apr 11, 10:28
by aml
I can now update my findings.

In the meanwhile, xplorer2 worked fine (I started each session with an Alt-h to check), except for today. Instead of seeing my regex search string and the "0", filtering was reset to "100" and "d*", which is a search string I may have used some weeks (!) ago, before setting my filtering to regex and exclusively filtering by regex from there on. On the other hand, xplorer2 was displayed correctly on my second screen, not on my main screen (which is the case when Windows does not close correctly every application).

This seems to indicate that the problem does not lie with correct/incorrect Windows shutdown. So I reset to "0" and did a new regex filter, then closed down x2 and searched the registry for my very last regex filter.

It was found two times, as second entry (value) in a 32-entry (value) list (the very first entry here always being "(default) (value not set)") in
HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\History\Filters

and as only entry (key "1") in
HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\Left pane settings\VisHFilt
but here in binary form, not readable for me.

Immediately below that correct second entry (regex search string) are TWO incorrect (non-regex) search strings, d* on third position and c* on fourth position; positions 5 to 31 are correct regex string values, position 32 stays empty.

(Even yesterday, I did several (!) regex filterings, but NO non-regex filtering, and I'm positive about this; even if my memory perhaps fails me for filterings during the last weeks, it does not fail me for my filterings during the very last session just 1 day ago.)

So this indicates that those, two, "current", filterings come from somwehere within xplorer2; both are non-regex filters I used several weeks ago only (d* on top (= second) position and c* on second position of the real values (i.e. on third position, including the "default value not set" which stays on top), before switching to exclusive regex filtering, and they are put into the very top list positions of my registry filter values.

I rechecked with another (exceptional, on-purpose) non-regex and another regex filtering, closing down x2, reopening it and rechecking the registry.

My regex filtering, on purpose, was one that is NOT yet stored within these 30 registry values, in order to see if value 32 was fille up now, too, but it stays empty.

Value 1 remains (default) (value not set), value 2 is my new (!) regex filter, value 3 is my for-checking non-regex filter, value 4 is the unwanted non-regex filter (d*) coming from nowhere and which today reset my setting from 0 to 100, value 5 is another (!) non-regex filter coming from nowhere (c*), values 6 to 31 are my regex filters from yesterday and the weeks before, and value 32 stays empty.

By the way, I do NOT have a registry hit anymore in that second key mentioned above, so that key could perhaps have been responsible today for that incorrect functioning (unwanted resetting from 0 to 100 and fetching a filter value from "nowhere", "months old" and very probably NOT in my 30-real-entry value filter list), and, I insist, not one but TWO unwanted new (or more correctly, ages-old) values, on these prominent positions 4 and 5 in my filter list, the value (now) on position 5 even weirder than the value on (now) position 4, since position 4 was seen today (unwanted though), on program start, as the current filter by checking by Alt-h, whilst the value on position 5 was not.

This seems to indicate that from somewhere, x2 sometimes only seems to fetch even several (here: two) unwanted filter values which indeed have been used some time, but which are probably not even in the 30-value filter list anymore (or then, perhaps on position 29 and 30, I cannot be absolute positive about this), putting them in on position 1 (and 2), from which then they go down further on.

Also, since this bug seems to re-occur once every some days, and since many weeks before, I used those non-regex filters indeed, but they reappear, then obviously go down the list, I now suppose that the bug is the following:

Whenever non-regex filter values reach the very last "real" positions (29 and 30, or 30 and 31 if you count the very first value "default-value not set", too), x2 put them on the very first list positions, from which then they go further down with each filtering, and then the same bug re-occurs.

Could you please check for this, or then some other bug which might cause what I describe above? Again, thank you very much for your kind interest in this matter.

Re: Regex search setting

Posted: 2016 Apr 11, 12:10
by nikos
these filters are shared in a number of dialogs, e.g. the search dialog and the filter dialog. If you change the filter in one, it will affect all the others. I don't think there's any hocus pocus here

Re: Regex search setting

Posted: 2016 Apr 11, 16:53
by aml
I know this from the help file, although I do not know which other dialogs are affected except filtering (Alt-h) and "Search files and folders" (control-f).

So I did control-f and happened to see this dialog for the very first time, in fact I never used it before. Here, it was "100" (!) and the very same regex (!) entry (search string) as in the filter dialog, and the other entries in the drop down list are equal to those in the filter dialog, too - no wonder since it's the same list from the registry.

I never use anything other than the filter dialog, and I'm more or less sure that the explanation I gave is correct: The unwanted non-regex entries will move down and down with every "new" entry, and then, at last position, instead of vanishing, they will jump to position 1 and 2; I'll check for this each day and will report.

And yes, you can rename bugs "hocuspocus", but they remain bugs.

Re: Regex search setting

Posted: 2016 Apr 11, 17:28
by nikos
if you can find a simple 1-2-3 reproducible course of action, then I will look into it

Re: Regex search setting

Posted: 2016 Apr 13, 09:15
by aml
Thank you.

Was not on my comp yesterday, checked this morning.

(a) Alt-f > "0" and my last (= from Monday) regex search.

Checked the drowdown.

Positions 1-8 = prefigured selections from {audio files} to {web files} in obviously alphabetic order (probably BECAUSE I never used them).

Then the 2 unwanted non-regex strings "c*" and "d*".

Then my regex filter string from Monday and which is preselected in the default field of the dropdown menu as in (a) before

THEN A THIRD, NEW UNWANTED non-regex search string "f*" !!!

This one I may have used 4 weeks ago, before setting up my regex searches, but not afterwards; it was NOT in the registry list Monday, but I cannot say if Monday it was hidden in the UPPER part of the drop-down menu (as are the {} entries which I never use either).

Comparison of my finding today to those of Monday seems to indicate that my Monday assumption (non-regexes going down the list as regexes do, then, instead of vanishing, jump back to top) was wrong, and that my INITIAL assumption (non-regexes come from "nowhere") is right.

So I checked the registry again, searching there for the "current" (a) regex string.

As first try on Monday, TWO finds for that, in

(b) HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\History\Filters\\00

1) (default) (value not set) (size: 0)
2) (searched) regex (a) in question
3) and 4) the known, unwanted non-regex
4) another regex
5) the NEW NON-regex
6) and up to one BEFORE last (= 31) are regexes
32) "IE" Type REG_SZ (as position 2 to 31) "Data" NOTHING, as in position 1 (and as before in this position), and size 2

And in

HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\Left pane settings\VisHFilt\\1
(format: REG_BINARY, data in binary form, size 85)

Since I checked the registry (b) Monday, I'm positive the "f*" (without the "") was NOT listed in (b), and I did not have the slightest reason to do a non-regex filtering, for "f* or other.

Since I CHECKED the search (control-f) Monday (but without executing any search), I recheckd it now, and it's "d*" over there, not "f*", so this "f*" comes "from nowhere".

So I now checked my registry for "f*" (again without the ""). 55 hits, but relevant for x2 seem to be

HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\History\Filters\\00
as was to be expected from the appearance in the dropdown list, of course,

and in

There, REG_BINARY, Size 104593

( Other entries in that key "ProgramsCache" of x2:
Favorites, FavoritesChanges, FavoritesResolve, (the the ProgramsCache), StartMenu_Balloon_Time and StartMenu_Start_Time )

The "c*", though, I also found in

HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\Left pane settings\\binDefaultSortCol
i.e. in the "parent key" of the aforementioned
HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\Left pane settings\VisHFilt
and there, the "Name"

szLastVFilter (REG_SZ)

So this does not help for the "f*", but, withouth knowing what is "szLastVFilter", I'm absolutely sure that "c*" was not my very last "szLastVFilter" either.

Perhaps this helps.

As those unwanted non-regexes seem to come from nowhere, deleting them in the registry list will very probably not exterminate them, which arises the question WHERE these strings could have been stored, too.

I know deleted (with x2 running!) the THREE unwanted non-regex keys from the list in
(b) HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\History\Filters\\00

THEN I closed x2, waited some seconds, then reopened it, and did Alt-h.

Now guess what I got?:

d* and 100 as default

And in the dropdown:

The 8 {} entries
c* (I must admit that my c* in fact begins and ends with " which may cause the non-alphabetical sort order)
2 regexes
All my other regexes

This time I closed x2 first, THEN I deleted the 3 registry keys (or "subkeys" or "values").

Guess what I got by Alt-h?
( Ditto for the registry
(b) HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\ZabaraKatranemia Plc\xplorer2_UC\History\Filters\\00
which I checked again, of course )

d* and 100

And in the dropdown:
The 8 {} entries

That's all. The deleted d* reappeared as did the deleted "c*", the deleted "f" was gone, as ALL of my regexes (which I hadn't touched in my registry editor).

(In my case, this is not important, since, as said, I do my regex filters by macro anyway, but a user who had done 30 regex filterings manually, would not be happy now.)

So I now close x2, then delete d* and c* in the registry (in the (b) key) again, then close down my pc, then restart it, and we'll see.

After restart of the computer, AND of x2:

d* and 100
The 8 {}
nothing else

Control-f (!):
d* and 100
dropdown: nothing!

Registry key (b):
f* remains vanished (for the time being), the deleted d*, c* are there, and all my regexes are there, too.

THUS, I now think:

- The idea to combine the search string list for searching AND for filtering was a good one, at the very least a defendable one.

- The idea to combine regex search/filtering (which otherwise works fine, I'm very pleased with it!), by the fuzzy value (0 instead of anything else), with the regular search, instead of clearly separating these (also with radio buttons "regular vs. regex") was sub-optimal since your code obviously got too complicated for easy, successful debugging:

Since from my finds, it becomes obvious that x2,
while combining non-regexes and regexes in ONE list,
treats "list HANDLING" (i.e. when and how to store or not to store) quite differently
(not speaking of the reset of the 0 to 100 and vice versa),

when in fact there should be IDENTICAL "handling" BEFORE and except actual search/filtering, with just 4 boolean variables for
- - "lastsearch was regex 1/true" (default being 0 for regular; this should affect the radio button for control-f) (or lastsearch was regular = true of course)
- - "lastfiltering was regex 1/true" (ditto for the Alt-h dialog)
- - and two for "CURRENT search/filtering is regex"

Then, the respective "current" value would update the respective "last" value AND trigger the (indeed very different) search/filtering.
(And then again, identical code does display the hit list, and similar for hit list "live" updates, for renamed (= new / not-anymore hits.)

As it is now, your obviously mixed-up / too-much-interwoven code design (regex added to regular search ex post) seems to have triggered some mixed-up / mixing-things-up code.


Re: Regex search setting

Posted: 2016 Aug 17, 15:57
by profess
I want to find a file which has 01s or 03s somewhere in its name. I do not want it to find 01f, 01 or 03. In this example it's "00s filename.jpg" but "something 02s something.jpg" may be a file name also.

The 2 numbers could change, ie 32s 52s but would always have an s at the end, ie "filename 32s file.jpg", "02s file.jpg".

Something I was finding and it seemed related? Covered before I think with ?? when using Ctrl+F and Find?


Re: Regex search setting

Posted: 2016 Aug 17, 16:01
by nikos
I am no regexp expert but a filter like

Code: Select all

should do it

Re: Regex search setting

Posted: 2016 Aug 17, 17:21
by profess
that works. it finds "vlc**55s928 " amongst it too. any way to refine it?

i set the regex? fuzzy search to 0, is this correct?

Re: Regex search setting

Posted: 2016 Aug 17, 17:32
by Kilmatead
Yes, Fuzzy to 0 for RegEx. To refine it to what you want (to not accidentally match other stuff) use:

Code: Select all

...which means "match two digits followed by an 's' if it's preceded by a non-digit or word-boundary (for zero-length) and consider the 's' as a word-boundary itself". Crazy, huh? :D

RegEx is friendly. Really. It is. Just keep repeating that to yourself and one day it might be true and it may smile back at you from the abyss. :wink:

Re: Regex search setting

Posted: 2016 Aug 18, 22:10
by profess
Thanks, though this does not find 'any' files, copying and pasting to Find in the same directory.

I was trying to get my head around the syntax and substituted and tinkered, but nothing worked.

Can this work in this field for Finding the name of a file?

Re: Regex search setting

Posted: 2016 Aug 19, 06:50
by Kilmatead
It works fine as long as you remember to set fuzzy to 0 first. Not being a complete cad, I took my time testing it before posting. :wink:

That said, what version of x2 are you using? If you're using anything prior to then it's a different story. If you are prior to 3.2 then replace the \d{2} with \d\d and that should do it (I think - I don't know if those versions recognise \b or not...)

Prior to 3.2 regex in x2 used a syntax that was evil, nonsensical, and not PERL friendly. There are still bugs being worked out as we speak as Nikos' email inbox will attest. (And as any farmer with a shotgun will tell you, if you ain't friendly to Perl, you ain't goin' home with no basket o' apples.) :D

Edit: A quick test of x2 2.5 show that no, it does not know what \b is or anything else... so... um... you're stuck with "\d\ds" (same as Nikos' above), unless you want to play with this and set "Upon completion: Hard Filter Items". That tool uses the PCRE RegEx engine so it will work with the full ([^\d]|\b)\d{2}s\b syntax. :shrug:

Sorry about that. Throw cow-pies at Nikos.

Re: Regex search setting

Posted: 2016 Aug 19, 07:49
by profess
tested thoroughly - as i'm sure you do.
upgraded to pro and that worked, thanks.