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
There:
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
HKEY_USERS\S-1-5-21-2403622860-3902631649-2670736347-1005\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\\ProgramsCache
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
d*
c* (I must admit that my c* in fact begins and ends with " which may cause the non-alphabetical sort order)
2 regexes
f*
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
d*
c*
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:
Alt-h:
d* and 100
dropdown:
The 8 {}
d*
c*
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.