I already had some saved searched that where nicely migrated from TC7, and decided I had to make a change to one of them. I loaded it, made the change, and saved it, and allowed to overwrite.
Then there were two exactly the same saved searches.
Unfortunately I cannot reproduce your problem. Here is what I tried:
1. Alt+F7 search (or choose from main menu)
2. Go to last tab load/save
3. Double click on a saved search (or single click+click on load)
4. Make some change
5. Click on the last tab again
6. Click on "Save"
7. Confirm overwrite
Result: The item is in the list just once.
Is there anything special with the name in the search? And did you use the 32-bit or 64-bit version?
Hmm.
Well it's nothing special. It was named "covers" and it searches for "covers|index|square" (regex) in the current directory (left it empty). I use the 64-bit version.
Confirmed. It happens only in the 64b version. Every time you overwrite some saved search, TC adds it as a new entry to the list of searches without removing the old one. When you close the search dialog and then reopen it, the list is in a proper state again.
I can reproduce it with a clean ini file in TC 8.0b19 x64
1. I save a simple search for *.htm and name it "HTML" (without quotes)
2. I load the "HTML" search
3. I save the search and accpet to overwrite "HTML"
4. Two "HTML" entries can be seen in the list
5. close and open the Find files dialog - and "HTML" is only in the list one time again.
No such behaviour in the 32bit version
License #524 (1994)
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14 TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Just installed beta 19. I can still produce this problem... Did I assume wrong in thinking that it would be fixed in b19?
Oops, I just found the changelog that I couldn't find before. Pretty verbose, but I don't think I see this problem noted as fixed in it. But maybe you described it differently
Thany wrote:Just installed beta 19. I can still produce this problem... Did I assume wrong in thinking that it would be fixed in b19?
I guess you did, 'cause beta 19 has been released a day before you've even opened the topic about the bug, and i'm pretty sure Christian doesn't have a time machine.