Rich Edit Control Odd "Find" Behavior - Solved

Introduction

I had an application that writes its text output to a rich edit control. There's code that implements the typical search operations - find text, find next occurrence, find previous occurrence - using CRichEditCtrl::FindTextEx; that's a MFC wrapper for the Windows EM_FINDTEXTEX message.  Although the very same search code worked in another application, it failed here.  It would match only the first character of the search string, e.g., search for "abcde" would find the next "a" in the text, regardless of what followed it.

And the Answer Is...

The project has configurations for both Unicode and 8-bit characters, although only the Unicode version gets used.  Therein lies the problem. When I assembled the UI using the UI builder in Visual Studio 2015, the 8-bit configuration must have been selected. The resulting resource script (.rc file) specified a rich edit control of type RichEdit20A.  Inspecting the .rc file for the working application showed a control of type RichEdit20W. Editing the offending resource file to specify the proper control solved the problem.

Conclusions

1. If you use rich edit controls in a Visual Studio application, be aware that there are two types and ensure that the right one is used.
2. If you attempt to build the same application in 8-bit and Unicode variants, it may take some customization of the otherwise automatically generated resource script.

History

• 20^th August, 2018: Initial version