2

I am working with an edit control in a dialog--all MFC. The only style specified in the resource is ES_AUTOHSCROLL. The dialog comes up and displays correctly. The edit control also works and edits text correctly--up until a point. At that point, it stops displaying text completely. The edit control is just blank.

My first thought was to try and adjust the limits of the edit control by sending calling SetLimitText() on the edit control which just sends EM_SETLIMITTEXT. I set a big number which was 10x the previous limit, and verified by EM_GETLIMITTEXT that the number retrieved is equal to the number set. After that, I still have the problem and nothing is changed.

Next I tried trapping EN_MAXTEXT and EN_ERRSPACE. Neither one of those notifications was sent.

Lastly, I started trying a little different input, and if I entered a space or a period then I could get a few more characters displayed than if I entered a W. The font in the dialog is MS Shell Dlg which on my system maps to Microsoft Sans Serif. It's a proportional font, do different characters have different widths, so I was beginning to thing that maybe it was GDI related.

Next, I trapped EN_CHANGE, and when it is fired off, I went and created an IC for the display, selected the font into the IC from the edit control, and then called GetTextExtent() on the text in the edit control. The problems occur in display right around 32760 which is darn near the 16-bit signed integer limit.

So, I am thinking that my problem is GDI related in that the EDIT control cannot draw past that limit. I tried substituting a RICHEDIT2 control, but it displayed fewer characters before going blank.

The other weird thing is that if I keep on entering characters and call GetWindowText() on the edit control, all the characters will be returned. It is just that the edit control is blank.

Yeah, maybe I shouldn't be displaying that many characters, but it is what it is.

Does anybody have a better explanation, solution, or workaround?

Joseph Willcoxson
  • 5,853
  • 1
  • 15
  • 29
  • 4
    There are several practical limitations to stuffing tens of thousands of characters in a single-line edit control. Beyond the user's dismay at such a horrible UI, at least one of them is the WM_HSCROLL message, it reports the scrollbar position as a 16-bit value packed into WPARAM. There is also an internal bug that quacks like an overflow problem if you go beyond that, making text disappear entirely. Create usable UI and you don't have a problem. – Hans Passant Oct 24 '14 at 18:35
  • Subclass the control and make it owner drawn? – Mark Ransom Oct 24 '14 at 18:35
  • I'd like to think of a better interface, but can't right now. It is a variable selection dialog for analytics. There is a listbox that contains all the variables, and edit box that reflects the selection. For contiguous variables, the edit control will show something like 1-100. The problem is when selection is non-contiguous, i.e. "1 3 5 7 12 14" etc. The interface is two way so that if the user enters "1-5" in the edit box, then variables 1-5 will be selected in the list box. After 13 years, this is the first report of this problem. Usually there are less variables and more contiguity. – Joseph Willcoxson Oct 24 '14 at 19:16
  • Even a multiline edit control would be a better interface, and you can implement that in about 10 seconds. – Jonathan Potter Oct 24 '14 at 20:17
  • I am not sure at all that multiline would be better. For variable selection, we can have sometimes up to 6 variable areas on a dialog to handle different types of variables depending on the analysis... Discriminants, continuous, predictors, etc. Space is somewhat of a premium, and also it is what the users are accustomed to. Honestly, for 99 44/100ths percent of the time, this is not an issue and most users only use the listbox to select variables. However, for that very small percentage, it is strange for the edit box to go blank. – Joseph Willcoxson Oct 24 '14 at 21:01

0 Answers0