Solving the problem instead of answering the question: How do I get this RichEdit control to look just like a static control?

A customer had a dialog box with two large text controls. Something like this:

FONT 8, "MS Shell Dlg", 400, 0, 0x0  

ICON   IDI_MAIN, -1, 0, 0
LTEXT  "Contoso Deluxe 2.0", 10, 0, 300, 24
LTEXT  "Check out all the new stuff in this version.",
       -1, 13, 17, 290, 20  
LTEXT  "New effects", -1, 43, 45, 270, 20  
LTEXT  "The super-blaster effect now blasts twice as \
much as the old blaster. Blast away with all your might!",
       -1, 43, 60, 225, 50  
LTEXT  "New styles", -1, 43, 115, 240, 20  
       SS_OWNERDRAW, 43, 131, 225, 87

The "super-blaster" text is rather long, but at least it fits under 255 characters, which is the limit for static text controls. The text that goes into the IDC_WHATS­NEW_STYLES_PLACEMENT control is longer than 255 characters, so the dialog creates a RichEdit control at runtime, places it where the IDC_WHATS­NEW_STYLES_PLACEMENT control goes, and fills the RichEdit with the required text.

The problem the customer had was that no matter how hard they tried, they couldn't get the RichEdit control to look the same as the static text control. In particular, they couldn't get the line spacing to match up, which results in an ugly inconsistency within the dialog box.

Their question was "How do I get this RichEdit control to look just like a static control?"

This is another case of an XY problem. The customer has a problem X: "I have some text that is too long to go into a static control." And the customer has an idea for a solution Y: "I know! I'll use a RichEdit control instead of a static control, and then I'll make the RichEdit control visually indistinguishable from a static control." The customer then asks for help with Y, when their real problem is X.

Fortunately, since the customer explained their entire scenario, we got to see what X is, and the solution to X doesn't involve a RichEdit control at all.

What the customer can do is change the last control to a plain text control:

       43, 131, 225, 87

And then instead of creating a RichEdit control at runtime, positioning it, and filling it with text, they simply fill the IDC_WHATS­NEW_STYLES_TEXT with the text.

The 255-character limit the customer observed is a limit of the resource compiler, not a limit of the static text control itself. The static text control will take as much text as you give it.

Comments (17)
  1. Darran Rowe says:

    Well, I can understand the confusion here though. I couldn’t find any kind of mention of a limit even with the resource compiler documentation. Of course, I could just be failing here.
    Anyway, you try to do something and you run into a problem, if there is no documentation available telling you that there is a limitation in the tools you are using then it is easier to assume that the problem is in the underlying implementation. It is especially true since there is no documentation saying that the static text control doesn’t have a limit. So from the developer’s point of view, both the resource compiler and static text control limits are implementation defined.

    1. Josh B says:

      Eventually, every page on MSDN will have “For further reading…” links to relevant Old New Thing posts. A whole team will be dedicated to internationalizing this blog, and knowledge will spread forever.

    2. Simon says:

      Yep… this is one of those cases where the customer is quite legitimately trying to work around a bug in the tools, and it’s not unreasonable that they might have assumed the limit was in the text control, not the resource file…

      1. zboot says:

        @Simon, what bug? To me, it’s like a customer who wants to buy gas up front using a 2gal gas can, but wants their car to behave as it the entire 10gal tank was filled and didn’t realize they could just buy 10gal cans. Customer ignorance is not a bug in the tool.

        1. The tool limitation is the resource compiler. But they didn’t realize that they didn’t need to switch to an entire new control. To take your analogy, it’s like a customer who wants 10 gallons of gas in their Camry but have only a 2 gallon can. To fix this, they buy a Prius, because the Prius has a 10-gallon tank, and they buy a 10 gallon can. But the Prius doesn’t look the same as a Camry, and they want help to make the Prius look more like a Camry. What they didn’t realizes is that the Camry also has a 10 gallon tank. They didn’t need to buy a Prius at all. All they needed to do was buy a 10 gallon can for their Camry.

  2. Brian_EE says:

    Shouldn’t they be applying the solution to all their strings so that they can support multiple languages?

  3. Dan says:

    Why can’t the resource compiler accept longer strings?

    1. Erkin Alp Güney says:

      Error reporting. Longer literals require more lookahead (and compilation gets slower).

    2. Neil says:

      This may be down to the fact that the packed resource format uses Pascal-style length-counted strings rather than C-style null-terminated strings (see and these would have been limited to 255 bytes in ANSI.

      1. waleri says:

        How using RichText control helps override resource compiler string length limitations?

        1. It doesn’t. That was a red herring.

          1. waleri says:

            It was a rhetorical question, but I am curious why such a limitation was introduced in a first place.

  4. Michael Quinlan says:

    “The static text control will take as much text as you give it.”

    How does Raymond know this? Is it part of the contract or is it an implementation detail?

    Just curious.

    1. Erkin Alp Güney says:

      Raymond is a major contributor in many Microsoft products, although being employed as a PR guy, he is specialised in backwards compatibility.

      1. I’m not employed by PR. I’m on the engineering team.

      2. Tom West says:

        > although being employed as a PR guy,

        Thank you. I laughed hard enough that my wife came to see what I’d read.

        Google “social skills of a thermonuclear device” – first entry (and we love him for it.)

Comments are closed.

Skip to main content