Rich Edit Control in raw Win32

Question

Is the documentation for Rich Edit Controls really as bad (wrong?) as it seems to be? Right now I'm manually calling LoadLibrary("riched20.dll") in order to get a Rich Edit Control to show up. The documentation for Rich Edit poorly demonstrates this in the first code sample for using Rich Edit controls.

It talks about calling InitCommonControlsEx() to add visual styles, but makes no mention of which flags to pass in.

Is there a better way to load a Rich Edit control?

http://msdn.microsoft.com/en-us/library/bb787877(VS.85).aspx

Here's the only code I could write to make it work:

#include "Richedit.h"
#include "commctrl.h"

INITCOMMONCONTROLSEX icex;
icex.dwSize = sizeof(INITCOMMONCONTROLSEX);
icex.dwICC = ICC_USEREX_CLASSES;  //Could be 0xFFFFFFFF and it still wouldn't work
InitCommonControlsEx(&icex);  //Does nothing for Rich Edit controls

LoadLibrary("riched20.dll");  //Manually?  For real?
hWndRichEdit = CreateWindowEx(
 ES_SUNKEN,
 RICHEDIT_CLASS,
 "",
 WS_BORDER | WS_VISIBLE | WS_CHILD,
 2, 2, 100, 24,
 hWnd, (HMENU) ID_RICH_EDIT, hInst, NULL);

Answer 1

Isn't there an import library (maybe riched20.lib) that you can link to. Then you won't have to load it "manually" at run time. That's how all the standard controls work. VS automatically adds a reference to user32.lib when you create a project.

Answer 2

I think you have to call CoInitializeEx before you create any of the common controls.

The LoadLibrary is not needed. If you link with the correct .lib file the exe-loader will take care of such details for you.

Answer 3

Using MFC, RichEdit controls just work.

Loading with InitCommonControlsEx() - ICC_USEREX_CLASSES doesn't load RichEdit AFAIK, you don't need it as it only does the 'standard' common controls, which don't include richedit. Apparently you only need to call this to enable 'visual styles' in Windows, not to get RichEdits working.

If you're using 2008, you want to include Msftedit.dll and use the MSFTEDIT_CLASS instead (MS are rubbish for backward compatibilty sometimes).

The docs do suggest you're doing it right for Win32 programming.

Answer 4

Many years ago, I ran into this same issue, and yes, the answer was to load the .dll manually. The reason, as far as I can remember, is that the RichEdit window class is registered in DllMain of riched20.dll.