Edit Control stops working when it is full

Question

Edit Control stops working when it is full

Bryan Kelly 516

Windows 11, Visual Studio 2022, C++, MFC

I have been having great difficulties getting the basics working.

I was directed here from another Microsoft forum. When posting the question the drop downs for tag, child tag, and child item tag, have nothing that looks like a programming question for Visual Studio. Am I in the wrong place? If so, please redirect me.

Basic Problem

The code can write to the Edit Controls. It cannot clear them. The debugger indicates that the lower level calls are are defective, even though they work when the Edit Control is not full. I suspect my declarations have a defect that but my knowledge is insufficient.

Details

This app does some 512 bit arithmetic using an array of uint64_t. It displays the numbers, in hex, in Edit controls. Below is the lowest level of my code that does the hex display. lp_cedit points to the edit control. lp_binary points to an array of ints, uint64_t.

lp_cedit->Clear(); // first two images are for this line and stepping in.

…

``for( int i = 0; i < U64_COUNT; i++) `` ``{

``lp_binary->u64t[i] = input->u64t[i]; // copy the number to the lp_binary

``hex_string.Format(_T("%016llX "), lp_binary->u64t[i]); // Format each 64-bit word as hex

``lp_cedit->SetSel(-1, -1); // Move the cursor to the end of the edit control

``lp_cedit->ReplaceSel(hex_string); // second two images for this line.

``}

The very first time the code attempts to display anything, in the debugger, at the Clear function, the Autos panel shows:

clear1

Step into the Clear function to see

clear2

The Autos display looks bad, but it does not assert. Visual Studio makes no sound.

Step out and down to the first call to ReplaceSel to see

replace1

Looks OK to me. Step in to find the below

This looks bad. BUT it writes to the edit control. Until the Edit Control is full of text. They are set to no scroll. Then the Clear() does nothing, does not assert, and the ReplaceSel() does nothing but it does assert.

The two critical pointers are declared and set as shown below

CEdit`` ``*lp_cedit = nullptr;``

td_512_uint *lp_binary = nullptr;

and used further down successfully

p_cedit = &m_edit_input_a;

p_select_binary = &m_512_input_a;

The ReplaceSel() works until the Edit Control is full. The Clear() function appears to never work but never asserts. It seems obvious to me that I have a setup wrong.

I am hoping someone with more experience can recognize the problem.

Yve-cg 90 Reputation points

2025-07-05T04:29:08.6433333+00:00

Thanks for all the details, Bryan! Just a few quick questions to help me understand your setup.

Is your Edit Control single-line or multi-line?

Did you turn off scrolling in your code or in the resource editor?

When Clear() or ReplaceSel() stop working, do you see any error messages? Or does nothing happen?

Have you tried using SetWindowText(_T("")) instead of Clear()? Did it make any difference?

Is the Edit Control ever set to read-only in your code?

Let me know what you find! If you're not sure about anything, I’m happy to help you check.
Bryan Kelly 516 Reputation points

2025-07-05T16:16:12.68+00:00

working the answer. Quick thoughts, Yes, the Edit Controls are set to no scroll at all because they will only display the large numbers in hex. Nothing in the code changes any of the Edit Control properties. I am reasonably good at writing software, but never did any user interface like Visual Studio and dialogs. This is much more difficult than expected, and understandably so. Still, frustrating. I will work the next answer also, but have some urgent items at home to attend to first.

Here is an image of the dialog to show the numbers. Normally there are four rows in each, but here, the display was cut off at two rows just to see that I could access each one a second time. They are no scroll and when full, I cannot clear them. I will try your suggestions later today. The buttons load test data to verify that the displays are correct.

Thank you again for your time and patience.

Accepted answer

0 additional answers

Your answer

Yve-cg 90 Reputation points

2025-07-05T04:29:08.6433333+00:00

Thanks for all the details, Bryan! Just a few quick questions to help me understand your setup.

Is your Edit Control single-line or multi-line?

Did you turn off scrolling in your code or in the resource editor?

When Clear() or ReplaceSel() stop working, do you see any error messages? Or does nothing happen?

Have you tried using SetWindowText(_T("")) instead of Clear()? Did it make any difference?

Is the Edit Control ever set to read-only in your code?

Let me know what you find! If you're not sure about anything, I’m happy to help you check.
Bryan Kelly 516 Reputation points

2025-07-05T16:16:12.68+00:00

working the answer. Quick thoughts, Yes, the Edit Controls are set to no scroll at all because they will only display the large numbers in hex. Nothing in the code changes any of the Edit Control properties. I am reasonably good at writing software, but never did any user interface like Visual Studio and dialogs. This is much more difficult than expected, and understandably so. Still, frustrating. I will work the next answer also, but have some urgent items at home to attend to first.

Here is an image of the dialog to show the numbers. Normally there are four rows in each, but here, the display was cut off at two rows just to see that I could access each one a second time. They are no scroll and when full, I cannot clear them. I will try your suggestions later today. The buttons load test data to verify that the displays are correct.

Thank you again for your time and patience.

Answer 1

Yve-cg 90

Hi Bryan,

Since I haven't heard back from you yet, I want to give you some practical steps you can try based on what you've shared so far. Hopefully, these help you move forward with your Edit Control issue:

Try this to clear the text. Instead of using Clear(), try this line: lp_cedit->SetWindowText(_T(""));
It's more reliable, even when the control is full.
Remove the text limit. If the control is full, it may not let you add or remove anything. Try this: lp_cedit->SetLimitText(0); // 0 means "no limit"
Is it single-line or multi-line?
Single-line controls have more limits and no scrolling. If you're showing a lot of text, switch to multi-line and turn on scrollbars.
Make sure it's not read-only. If the control is read-only, it won't let you change anything. To make sure it's editable: lp_cedit->SetReadOnly(FALSE);
Double-check your pointer. Make sure lp_cedit always point to the right control and isn't null.

If none of these work, we can look deeper at how the control is set up or how the data is handled. Try them out and let me know what happens. I'm here to help you figure it out.

Bryan Kelly 516 Reputation points

2025-07-05T18:00:45.76+00:00

I copied your reply and started working and editing. One of your suggestions works, jump down to the line with AND THAT MAKES IT ALL WORK

I don’t want to be too long winded, but, I suspect several of these points are important.

Is your Edit Control single-line or multi-line?

It is multi line, see the image in my previous comment. Those Edit Controls are sized to just fit eight 64 bit numbers displayed as hex. I posted some questions here and setting to no scroll, vertical and horizontal, seemed to be the best way.

Did you turn off scrolling in your code or in the resource editor?

Turned on via the properties page, which was accessed via the Resource editor. I did not change any properties with my code.

When Clear() or ReplaceSel() stop working, do you see any error messages? Or does nothing happen?

Clear() never seems to have worked. ReplaceSel() does not work with the Edit Control is full. There is no message, just the audio signal from Visual Studio when it does the ASSERT.

Have you tried using SetWindowText(_T("")) instead of Clear()? Did it make any difference?

I just tried that, no effect.

Is the Edit Control ever set to read-only in your code?

My code never sets any Edit Control properties. Read Only is set to False.

The second reply contains: Remove the text limit. If the control is full, it may not let you add or remove anything. Try this: lp_cedit->SetLimitText(0); // 0 means "no limit"

Where should this be put? I wrote a too long explanation but the essence is this. There is a variable for each Edit Control and the declaration and general format is:

            CEdit m_edit_input_a;

It is used, and works, but I don’t see anything that explicitly sets it, initializes it. I tried putting the new line in the constructor as in:

C_Show_Long_Numbers::C_Show_Long_Numbers(CWnd* pParent /*=nullptr*/)

            ``: CDialog(IDD_SHOW_NUMBERS, pParent)

{

   ``a_ptr_show_long_numbers = this; //

   ``m_edit_input_a.SetLimitText(0);

}

When the debugger gets there there is a Debug Assertion Failed popup.

So I put the code in the button that loads the initial test data. A button for the user, namely me

AND THAT MAKES IT ALL WORK

This seems to be a defect. Having an Edit Control full of text should not prevent it from being cleared. That is kind of crazy.

However, that seems to work so go with it.

This leaves two questions / points.

First, where in the code should the SetLimitText(0) be put? In the constructor did not work. Putting it in a button that may not be used later will work for now but is not a good solution. That line, for each Edit Control, should be in a place such that it is executed when the window is first opened. Where is that?

Second, set a breakpoint on the line

lp_cedit->ReplaceSel(hex_string);

This is where all the hex data is written, all of it. Break there and Autos panel looks good. Step in to get to file afxwin2.inl line 896. The Autos panel looks like the below.

In particular is what seems to be the “this” pointer set to, hex, all “c” an uninitialized value. Same for the two fields above it. But it functions with no warnings from VS. What am I missing here?

Thank you again for your time and patience.
Yve-cg 90 Reputation points

2025-07-05T18:42:20.35+00:00
Thanks for the update and nice work getting the SetLimitText(0) to work! That's a solid step forward.

Let me walk you through the two things you asked about.

Where to call SetLimitText(0)
You're right, if you call it too early (like in the constructor), it won't do anything because the Edit Control hasn't been fully created yet.

The best place to put it is OnInitDialog().
That's the function that runs after all controls are set up and just before the dialog shows.

Here's what it looks like:

BOOL C_Show_Long_Numbers::OnInitDialog() { CDialog::OnInitDialog(); m_edit_input_a.SetLimitText(0); // remove text limit // Add this for other edit controls too return TRUE; // return TRUE unless you want to set focus to a control }

About that 0xccccccc value

That just means the memory hasn't been set up yet. It's something Visual Studio shows in debug mode to flat uninitiated variables.

But if you ever see it for your own variables (like m_edit_input_a ) before you use them, it means they haven't been properly initialized yet, and you should-double-check your initialization code.

Quick recap:

Put SetLimitText(0) in OnInitDialog()

Ignore 0xcccccccc unless it shows up in your own variables

Let me know if you want help double-checking your OnInitDialog() code or anything else. You're really close to wrapping this up.
Bryan Kelly 516 Reputation points

2025-07-05T21:43:27.2+00:00

The 0xcccccccc comment. Ok, I can deal with that.

The code for OnInitdialog();

The class C_Show_Long_Numbers was automatically created when I followed to steps to create that dialog. In that .cpp file, there is no function OnInitDialog(). There are several other classes so searched the entire project and there is only one occurence, in class C_Long_Arithmetic. That is what I call the core class, the first one created. It is created and functional before any other dialog is opened / created. This is rather puzzling to me.

So the new code cannot go in there.

In the class. the cpp file, that contains the dialog and those Edit Controls the list of functions includes

_Show_Long_Numbers::C_Show_Long_Numbers(CWnd* pParent /*=nullptr*/)

C_Show_Long_Numbers::~C_Show_Long_Numbers() // empty function

void C_Show_Long_Numbers::DoDataExchange(CDataExchange* pDX)

BEGIN_MESSAGE_MAP(C_Show_Long_Numbers, CDialog)

followed by the functions I have written.

Where else should I look for placing this code? Should I create an OnInitDialog() using the format for the one that does exist?
Yve-cg 90 Reputation points

2025-07-05T23:43:35.6666667+00:00
Great question. If you dialog class doesn't have an OnInitDialog() function yet, don't worry that's totally normal. You can add it yourself. This often happens with dialogs created by the Visual Studio wizard.

The reason we use OnInitDialog() is that it runs after all the controls have been created but before the dialog is shown. That means it's the perfect place to set properties like SetLimitText(0) on your Edit Controls, so they're ready to go when the user sees the dialog.

Here's how to add it:

Open your header file ( C_Show_Long_Numbers.h )

Under the public: section of your class, add this line:

virtual BOOL OnInitDialog();

Open your cpp file ( C_Show_Long_Numbers.cpp )

Add this function (a good spot is right after your constructor):

BOOL C_Show_Long_Numbers::OnInitDialog() { CDialog::OnInitDialog(); m_edit_input_a.SetLimitText(0); // remove text limit // Do the same for other Edit Controls if needed return TRUE; // return TRUE unless you want to set focus to a control }

That's it, no need to change anything else.

MFC will automatically call OnInitDialog() when your dialog opens.

Quick recap:

It's normal to add OnInitDialog() if it's missing.

Declare it in the header file, then define if in the cpp file.

Use it to set up your controls once they're created, like removing text limits.

You're almost there, Bryan! Hope this works.
Bryan Kelly 516 Reputation points

2025-07-06T03:20:16.02+00:00

Well that is wonderful. The app is working as desired now.

When I started editing the new OnInitDialog() method, the first new line of code was:

m_edit_input_a.SetLimitText(0);

and Copilot put in the next four lines for me.

m_edit_input_b.SetLimitText(0);

m_edit_input_temp.SetLimitText(0);

m_edit_input_carry.SetLimitText(0);

m_edit_input_result.SetLimitText(0);

Copilot found the right variables and put them in the right places.

While it guesses wrong frequently, it is right so often it is ABSOLUTLY AMAZING. And the in-depth analysis to come up with the right code is awesome.

On that one, Copilot added these two lines in OnInitDialog()

SetIcon(AfxGetApp()->LoadIcon(IDR_MAINFRAME), TRUE); // Set big icon

SetIcon(AfxGetApp()->LoadIcon(IDR_MAINFRAME), FALSE); // Set small icon

I presume it wanted me to see both options. So each was enabled one at a time and I detected no difference. Looked up the function and yeah, it sets the size of the icon. But I did not see any icons. I started the app and minimized everything else, but no icon. Do you know what this is?

Significant Point

The Edit Control was full of text, and the clear function could not clear it. Two clear functions could not do the job. To me, that is a defect in the Edit Control class. Do you agree? Can you report this to someone?

And now to finish well:

Yve-cg, You came up with the right answer. Given the complexity, you did it very quickly.

Thank you very much for your time and patience.
Yve-cg 90 Reputation points

2025-07-06T03:52:57.69+00:00

That's awesome news! I'm really glad your app is working the way you want now. And yep, Copilot can be lifesaver sometimes. It's pretty cool when it just knows what you need next.

About those icon lines Copilot added are meant to show an icon in the title bar or taskbar. If you're not seeing anything, that's ok. Some dialogs just don't show icons, or maybe your app doesn't have one linked to IDR_MAINFRAME. You can leave those lines in or take them out, your app will work fine either way.

About the Edit Control not clearing. I totally agree, it's not very clear that Edit Control stops working when it's full unless you set a text limit. It does feel like something that should just work. This behavior comes from how Windows handles Edit Controls behind the scenes. Unfortunately, not much we can do to change it, but you're not alone in thinking it's a bit strange. If you ever want to submit a feedback or suggestions, the Visual Studio Developer Community or Microsoft's UserVoice channels is a good place to do that to raise awareness.

Thanks for the kind words, Bryan! I'm glad we could get this sorted out together, reach out if you run into anything else. Take care and all the best with your project!

Share via

Edit Control stops working when it is full

0 additional answers

Your answer