0X00000590

Fix ERROR_INVALID_EDIT_HEIGHT (0X00000590) – Height limit 256

Windows Errors Intermediate 👁 0 views 📅 May 28, 2026

This error means your edit control height exceeds 255 pixels. I'll show you how to resize it safely in Windows 10/11.

Quick answer

Your edit control height is set to 256 or more pixels. Drop it to 255 or less in your resource file (.rc) or dialog editor.

Why this happens

This error usually pops up when you're working on a Win32 or MFC application — most commonly in Visual Studio's resource editor. You dragged an edit control a bit too tall, saved the .rc file, and boom — you get ERROR_INVALID_EDIT_HEIGHT (0X00000590) when the resource compiler (RC.exe) tries to compile it. The real surprise? The error message says "Height must be less than 256," but the actual limit is 255 pixels. Microsoft's docs call it a legacy limit from Windows 95 era. It still applies today in Windows 10 and 11.

I've seen this most often when someone tries to make a multi-line edit box that fills a large dialog area. You think, "I'll just make it tall," and the compiler slaps you. Another common trigger: resizing controls programmatically and accidentally passing a height of 256 or more to SetWindowPos or MoveWindow during initialization.

Fix steps

  1. Open your .rc file in a text editor (Notepad, VS Code, or the Visual Studio resource editor).
  2. Find the offending edit control. Search for EDITTEXT or CONTROL with class Edit. Look for a line like this:
    EDITTEXT IDC_MYEDIT, 10, 10, 200, 260
    The last number (260) is the height. Change it to 255 or less.
  3. Save the .rc file and rebuild your project.

Alternative fixes

If the above doesn't work, try these:

  • Use Visual Studio resource editor: Open the .rc file, select the edit control, and set the Height property in the Properties window to 255 or less. Save and rebuild.
  • Check your dialog template: If you're using DialogBox or CreateDialog, open the .rc file and manually verify heights of all edit controls. I've seen cases where one tall control hides behind another — you think it's fixed but the compiler still sees the old height.
  • If you're using a custom control class, check if you're setting the height to 256 somewhere in code after creation. Use GetWindowRect and SetWindowPos with a clamped height:
    RECT rc; GetWindowRect(hEdit, &rc); int height = rc.bottom - rc.top; if (height > 255) { SetWindowPos(hEdit, NULL, 0, 0, rc.right - rc.left, 255, SWP_NOMOVE | SWP_NOZORDER); }
  • Last resort: Delete the control from the .rc file and re-add it. Sometimes the resource editor caches bad values. I've had to do this twice in 6 years — not common, but it works.

Prevention tip

Set a hard limit in your resource editor before you start laying out dialogs. In Visual Studio, I keep a mental note: edit control height never exceeds 200 pixels unless it's a multi-line box that needs to show 10+ lines. For those, I use list boxes or rich edit controls instead — they don't have the 255 pixel limit. Also, run the resource compiler early and often: hit Ctrl+Shift+B (Build) after every few changes. Don't wait until you have 50 controls. That's how you waste an hour hunting down one rogue height.

One more thing: if you're targeting Windows 10 or 11, you can safely use RICHEDIT (Riched20.dll or Riched32.dll) — no height limit, more features. Just add RICHEDIT to your .rc file's includes and update the control class. It's a five-minute fix that buys you freedom.

Was this solution helpful?