Share via

Rich edit control that displays emojis with color.

technoway 241 Reputation points
2026-06-04T05:08:28.99+00:00

Please only answer if you are in Microsoft since part of this question regards right to distribute a DLL.
This regards a C/C++program I wrote. I created a rich edit control using CreateWindowEx and subclassed the edit control. I used msftedit.dll. I need it to display text, similar to Notepad.exe.
The emojis were displayed in black and white.
So, I wrote what I'd call research code using Direct2D, using text layout, and I got it to display color emojis. I've handled descenders, got scrolling to work, can change the font size with the mouse wheel, do hit testing in the paint function so I can cut-and_paste text, and more. I still have minor bugs to work out, but mostly it works.

Before I refactor all this code into a reusable object, I'm wondering if my approach is correct. For example, I read "richedit20.dll" will just support emojis in color, although I think that DLL is not redistributable, and is part of Microsoft 365 (Microsoft Office?). My guess is that DLL cannot be redistributed.

For C/C++, is there a better approach than using Direct2D to create an edit control that can display multiple fonts in and emojis in color?

Developer technologies | C++
Developer technologies | C++

A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Taki Ly (WICLOUD CORPORATION) 1,825 Reputation points Microsoft External Staff Moderator
    2026-06-04T07:10:04.3866667+00:00

    Hello @technoway ,

    Thanks for reaching out.

    Since your question touches on the licensing aspects of redistributing DLLs as well as technical approaches, I would like to offer some thoughts based on Microsoft documentation that might help guide your next steps.

    1. Regarding the redistribution of richedit20.dll

    From what I gather, your guess about the Office or Microsoft 365 DLL being non-redistributable seems to be correct. Generally, under Microsoft licensing terms, you are only permitted to redistribute files that are explicitly listed in the official "Distributable Code" list (historically known as the REDIST list).

    I recently reviewed the latest Distributable Code list for Visual Studio 2022. You can find it online at Distributable Code Files for Visual Studio 2022 or check the Redist.txt file located in the \Licenses\1033\ folder of your Visual Studio installation. It appears that neither richedit20.dll (which is part of the Office suite) nor msftedit.dll (which is an underlying OS component) is included in that list.

    According to the general guidance on Determining which DLLs to redistribute, if a file is not on the approved list, it typically cannot be shipped with your application. Trying to bundle the Office DLL might lead to licensing compliance issues, so I would suggest avoiding that route.

    2. Are there better approaches for C/C++?

    Your Direct2D approach is actually very sound because it is essentially doing what the modern controls do under the hood. If you are already close to finishing and performance is your top priority, you might just want to polish it up and wrap it in a reusable class.

    However, if you are looking for an alternative that saves you from reinventing the wheel (handling selection, scrolling, etc.), you might want to explore the following options:

    • Option A: XAML Islands and WinUI 3 If you would like a built-in solution that handles color emojis, touch, and modern interactions flawlessly, you might want to look into using a modern RichEditBox via XAML Islands. This technology allows you to host WinRT XAML controls inside your classic Win32 C++ application.
    • Option B: Enhancing the system msftedit.dll If you prefer to stick with the classic Win32 control, msftedit.dll (specifically the RICHEDIT50W class) on recent versions of Windows does seem to have some level of support for DirectWrite color fonts. You might be able to achieve color emoji rendering by sending the EM_SETCHARFORMAT message to specify a font capable of color (like "Segoe UI Emoji").

    I hope these links provide some helpful context for your project. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

    Thank you.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-04T05:08:52.0666667+00:00

    Direct2D plus DirectWrite is the correct and recommended approach for rendering color emoji and other color fonts in a custom C/C++ text/edit control.

    Rich edit controls (including those created via CreateWindowEx using MSFTEDIT_CLASS and the various RichEdit DLLs) are primarily designed around traditional monochrome glyph rendering. The documentation for rich edit controls focuses on rich text features (multiline, complex scripts, tables, styles, etc.) and does not describe built-in support for color fonts or emoji rendering beyond standard text capabilities.

    By contrast, the Windows text stack explicitly supports color fonts through DirectWrite and Direct2D. Color fonts (such as Segoe UI Emoji) are defined as fonts that contain multiple colored layers per glyph. To render those color glyphs, apps must use the color-aware glyph rendering APIs instead of the classic monochrome DrawGlyphRun path.

    The DirectWrite/Direct2D color font guidance is:

    • Color fonts are fonts that include color information in addition to glyph outlines.
    • Monochrome rendering uses the standard DrawGlyphRun methods, which fill glyph shapes with a single color.
    • To render color glyphs, apps must use the color font–aware APIs, such as ID2D1DeviceContext7::DrawGlyphRunWithColorSupport, or the TranslateColorGlyphRun path when ID2D1DeviceContext7 is not available.
    • A sample TextRenderer::DrawGlyphRun implementation shows how to integrate these APIs in an IDWriteTextRenderer implementation to render color glyph runs via Direct2D.

    This is essentially what the existing Direct2D-based solution is doing: using DirectWrite text layout plus a color-aware glyph rendering path to draw emoji in color. That aligns with the documented model for color fonts and is the appropriate way to build a custom control that supports multiple fonts and color emoji.

    For XAML-based apps (TextBlock, RichTextBlock, TextBox, RichEditBox), color fonts are supported automatically via the IsColorFontEnabled property, which defaults to true. Those controls fall back to the system’s Segoe UI Emoji font to display emoji in color. However, that automatic support is specific to those XAML controls and does not apply to Win32 rich edit controls created via CreateWindowEx.

    For a custom Win32 C/C++ control that behaves like a rich edit or Notepad-style editor but needs color emoji and multiple fonts, the documented and scalable approach is:

    1. Use DirectWrite for text layout (including multiple fonts and complex scripts).
    2. Use Direct2D for rendering, specifically the color font–aware glyph rendering APIs.
    3. Implement an IDWriteTextRenderer (or similar abstraction) to integrate layout, hit-testing, scrolling, selection, and editing behavior.

    There is no alternative in the provided documentation that offers richer color-emoji support in a Win32 rich edit control DLL than what is already achieved with Direct2D/DirectWrite. The Direct2D/DirectWrite approach is therefore the appropriate and supported path.

    (Questions about redistribution rights for specific DLLs are out of scope of the provided technical documentation.)

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.