The text from GetNextLine is passed directly to the search engine without any further processing. HRESULT GetNextLine( BSTR* pbstrText, LONG* pnLine) You'd need to implement IExtDataInterpreter which has three methods: HRESULT Open( BSTR bstrPathName) You could write a COM component to replace the file reading process with your own. This occurs at quite a low level in the file processing process. The text files are loaded and valid EOL characters are replaced with , invalid EOL characters are removed.

Would match to ABC with a LF but not ABC with CR LF.įileLocator Pro does not pass the raw text to the regex engine. If you choose that option you should be able to search for CR, LF, e.g. The only containing text expression type that doesn't remove the CR or LF characters is the Multi-line RegEx. Lastly, does the software as a whole use a different regular expressions engine than the tester? When I test all of the expressions described in the Regular Expressions Tester, my regex searches are working exactly as desired (with being treated as distinct from and with it not returning a match when I'm searching for ABC and the text being searched actually matches a pattern of ABC . What I'm finding is that even when I turn off CR (by itself) as an EOL indicator in the configuration, the system will not match using (line feed) and I must still use (carriage return) to indicate the EOL (though they are not the same), and it is still returning a match to ABC when the item in question actually matches the pattern ABC . Other files in the same path will have the ABC or the DEF pattern and I do not want to match them. I'm trying to search for files that include have text followed immediately by a line feed ( ) with nothing in between the text and the line feed (so ABC should return a match but DEF should not).

Filelocator pro containing text