Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Rich Edit Control Odd Find Behavior - Solved

0.00/5 (No votes)
20 Aug 2018 1  
A rich edit control's find text operation failed, but the same code worked in another program.

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

  • 20th August, 2018: Initial version

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here