CodeLite IDE

Hello All,
I'm having a problem with the Find in Files function (binoculars) in CodeLite. I searched on the text "WDTReset" in the files in the Entire Workspace, and got only a portion of the matches that I got using grep from a command window. I tried finding the same string in the Entire Workspace, Active Project, and then Browsed to the same folder that I used grep on. All results were consistent, but incorrect. It seems the find function of CodeLite is not searching the file WDT.c for some strange reason. Anyone else run into problems using "Find in Files" or am I just the lucky one? Here is attached output of grep and FIF function:

Grep Output

if_control.c: CRAM.Control.ResetCount = WDTResetCount;
io_crom.c: * Reference watchdog reset count (WDTResetCount)
io_crom.c: else if (WDTResetCount)
wdt.c:* In the wdt test, moved the updating of WDTResetCount just after the end
wdt.c:* Made changes to update WDTResetCount only at the end of the wdt_test.
wdt.c:* Add watchdog reset count WDTResetCount per SRS.
wdt.c:uint8_t WDTResetCount = 0;
wdt.c: WDTResetCount = (uint8_t)(pld->resets_wdt3x.read.wdt_fault_count);
wdt.h:* Add watchdog reset count WDTResetCount per SRS.
wdt.h:extern uint8_t WDTResetCount;

CodeLite Find in Files Output

====== Searching for: 'WDTReset'; Match case: false ; Match whole word: false ; Regular expression: false ======
W:\emc61\software\users\kehrhardt\engine_controls\EMC61\C-nnnn-xxxx\src\if_control.c
136: [control_oss_to_as_xfer_cram] CRAM.Control.ResetCount = WDTResetCount;
W:\emc61\software\users\kehrhardt\engine_controls\EMC61\C-nnnn-xxxx\src\io_crom.c
53: * Reference watchdog reset count (WDTResetCount)
224: [reset_type] else if (WDTResetCount)
W:\emc61\software\users\kehrhardt\engine_controls\EMC61\C-nnnn-xxxx\src\wdt.h
34: * Add watchdog reset count WDTResetCount per SRS.
106: extern uint8_t WDTResetCount;
====== Number of files scanned: 304, Matches found: 5, elapsed time: 5:983 sec ======

Is the file is part of your workspace?

If it is, do you use any non US-ASCII characters? (umlaut etc.), if the answer is yes do this:
- open the editor settings (settings -> editor -> misc) and set your encoding (default is set to 'UTF8')
- in the find in files dialog, tick the option that says: 'use the editor's font encoding' and try to search again

Eran

eranif wrote:Is the file is part of your workspace?

If it is, do you use any non US-ASCII characters? (umlaut etc.), if the answer is yes do this:
- open the editor settings (settings -> editor -> misc) and set your encoding (default is set to 'UTF8')
- in the find in files dialog, tick the option that says: 'use the editor's font encoding' and try to search again

Eran

Yes, the file is part of the workspace. I have one project in the workspace and several 'Virtual Folders' under that project. I use the virual folders to segment the file types like applying filters in CodeWright (i.e. Source Files, Include Files, Make Files, Linker Files, Assembly Files). WDT.c is part of the Source Files virtual folder.

No non-ascii characters are used. I edited WDT.c with a hex editor an the string I am looking for is ASCII.

Opened editor settings, encoding is UTF8, tried other settings, no go.

Tried use editors font encoding, no go.

Its almost like the find function is not opening the WDT.c file. Is there an error log file that CodeLite creates that can be inspected for errors?

I even tried moving the line that contained the path to WDT.c file in the project file. It was the last entry in the virtual folder. I thought there might be a search problem with it being the last entry. No go. Is this list of files in the project file supposed to be in alphabetic order, or can it be in any order?

Can u zip and upload/send me the offending file? with the searched text to search?

Eran

Eran,
Unfortunately, can't do that per client's rules. Sorry. I'm working around it for now, will have post more info when I get the chance. Thanks.

Hi KEhrhardt,

Can you try these steps?
- In Explorer, find the file MDT.c, right click it, and choose Search...
- Alternatively, change the "file types" mask to "*" or "*.*".

Do either of these methods work?

Scott

sdolim wrote:Hi KEhrhardt,

Can you try these steps?
- In Explorer, find the file MDT.c, right click it, and choose Search...
- Alternatively, change the "file types" mask to "*" or "*.*".

Do either of these methods work?

Scott

Been there but I will try again....

Just tried, neither above search technique works from within CodeLite. However, running grep from an external command prompt window works without problems. In fact, I have created an external tool command prompt shell from within CodeLite and running grep in that window works as well. Hrrmmmm?

Any of these work:

grep WDTReset *.c
grep WDTReset *.*
grep WDTReset wdt.c

When I fully specify the full file path (<path>\wdt.c) in the FIF from within CodeLite, the output says 1 file was scanned, but no matches occur. Must be something with this file it doesn't like?

Yes, I was trying to determine if the problem was either:

• CL not scanning the file at all, or
• CL scanning the file but not matching your text

It appears to be #2, so the problem is in the CL string-matching code, relative to the content of this file.

Scott

Like I said in first reply: the problem is probably with encoding problem. Try to scan it and search for non-ascii characters this is most likely the cause

Eran

Since you can't reasonably show us your client's code, there's another test to try. But it might be a little involved:

• Make a copy of MDT.c, say MDT2.c, and add it to the workspace.
• Verify that FIF also fails for the new file.
• Now start chopping out bits of MDT2.c until you either:
  • get a match, or
  • reduce it to just a few lines around your known occurrence

At that point you will have isolated the part of the file that is tripping up CL's string matcher. Hopefully that chunk will be small enough that you could share it. If not, perhaps replace all alphanumeric characters (other than the word you're looking for) with something like "_".

Sorry this is so complicated, and I understand if you don't have the time or inclination to pursue this. It sounds like an important issue, but it's obviously one that is hard to reproduce.

Scott