FindInFiles bug

[lklawrie]

This is not really a bug. I have Textpad running on 3 machines.

On one of them, FindInFiles does not work. I put in the parameters, press the button and nothing happens.

The other two are fine.

I've reinstalled, removed, installed. No idea????

[AmigoJack]

• Have you used the "Defaults" button to make sure you're not forgetting one of the search settings?
• Have you checked that the folder to start the search in has read access? Because TextPad only tests if it exists in the first place, but getting its content is a different story.
• Have you tried various folders to start the search in? In doubt folders like C:Users (without searching subfolders).

[lklawrie]

Have you used the "Defaults" button to make sure you're not forgetting one of the search settings?

yes. i am a loooooong time user of textpad besides.

Have you checked that the folder to start the search in has read access? Because TextPad only tests if it exists in the first place, but getting its content is a different story.

Searching in same folders from other computers works fine so don't think this is the problem.

Have you tried various folders to start the search in? In doubt folders like C:Users (without searching subfolders).

Yes.

[lklawrie]

I posted this quite a while ago and the FindInFiles error is persisting on my machine where it had the problem before.

I installed V9 to see if it would help. Seemed to help yesterday. This morning, it's back to not working.

Will try Ultraedit and see. I really liked Textpad though.

[AmigoJack]

Does really "nothing" happen? You click the "Find" button and it remains enabled, instead of signaling that a work is in progress by being disabled? And the "Find" button can be clicked on in the first place? Because not entering any search term will leave it disabled, thus unclickable. And the "Close" button stays with that caption instead of switching to the caption "Cancel"? And no "Search Results" document is displayed, telling you the search has finished?

I'm surprised it really doesn't work with any starting folder and any search terms and you're not overlooking that TextPad might run with a different user account, thus having different permissions - you just wrote "3 machines", not even pointing out if they're all the same Windows version/patch level.

[lklawrie]

It "works". But gives me 0 finds even though there are some.

And it worked at one point and later in the same day failed (that is said there were 0)

I call that a bug.

[bbadmin]

What's the encoding of the files you are searching? Is the default encoding on Configure » Preferences » Document Classes » Search Results the same as on the PCs that work?

[lklawrie]

What's the encoding of the files you are searching? Is the default encoding on Configure » Preferences » Document Classes » Search Results the same as on the PCs that work?

default encoding: Ansi

And note. On this machine that doesn't produce any found items, it worked earlier after I had just installed V9. Then, it didn't.

Because of other problems, I have to return to V8. Hopefully i can reinstall it.

[bbadmin]

This is a puzzle. The code that implements Find in Files is identical in v8 and v9, and hasn't been changed since 2018. The code for the user interface dialog box only differs in the handling of the regular expression builder and to resize the box.

When a search is in progress, each file is briefly shown at the bottom of the dialog box, and the number of occurrences found and number of files searched is shown when it completes. Are they different in v8 and v9?

If you close v9 and delete or rename %APPDATA%\Helios\TextPad\9\ConfigState.xml, it will be recreated with default settings next time you start v9. Does that make any difference?

[lklawrie]

FYI, the reason I installed V9 was that it wasn't working in V8 on this machine.

However, V9 has other problems ref: https://forums.textpad.com/viewtopic.php?p=45369#p45369

So, I am reinstalling V8. Presumably with default installs as V9 appears to have deleted the V8 install.

[bbadmin]

Linda, I'm trying to narrow down the cause of the problem you've reported. I can't see what's happening on your PC, so have to rely on you to answer my questions. These apply equally to v8 & 9, except for the "9" in the %APPDATA% path:

1. What text is in each of the edit controls on the dialog box?
2. Is the problem that the Find button does nothing because it's disabled?
3. Is anything reported in the Search Results window?
4. Is the Search Results window visible?
5. Is the Search Results window docked?
6. Does it work, after closing TextPad and deleting %APPDATA%\Helios\TextPad\9\ConfigState.xml?
7. Does it work, after closing TextPad and deleting %APPDATA%\Helios\TextPad\9\GUIConfig.xml?
8. Is the PC that it doesn't work on a similar specification as the others?

Thanks.

[lklawrie]

I am not ignoring answering your questions. Since I uninstalled V9 and reinstalled V8, it appears to be working properly.

No idea why or why it didn't.

Wanted to make sure it lasted over a reboot.

So far, so good.

[AmigoJack]

bbadmin, let's assume there really is no obscure detail missing for this case and it really happens only by chance. If it's unpredictable, then it's most likely random memory, as in: not fully initializing memory at some point. Maybe it fully works in a 32 bit version, but only by chance (but very often tho) in a 64 bit version. Or vice versa.

At some point the code may assume that a string (or other variable) is filled with NULL bytes, when in fact this is nowhere assured and may just happen by chance. The string for the path may be affected by that, leading to (trying to) list the content of a directory that then doesn't exist (turns out as C:\Users\lklawrie\5#_U".@. Or the file mask may be affected, effectively becoming *.htmlP8+/)~ or such. Maybe the code for both 32 bit and 64 bit is not fully correct, but for reasons yet unknown to us it still fully works for one platform, but only 99.9% on the other.

[bbadmin]

Memory faults are a possible cause and can be checked for as described here:

https://www.techrepublic.com/article/ho ... stic-tool/

However, that would more likely impact more things than just one aspect of TextPad, so I'd also do a surface scan to check for hard drive faults as described here:

https://www.avast.com/c-chkdsk-windows

If TextPad.exe is sitting on a bad sector, that would affect only it.