Edit control not drawing contents in Windows 7 (or Server 2008) when text exceeds a certain length
-
Hi, [I have posted this already on the C/C++/MFC forum, but have since found that it is a Windows thing rather than a C/C++/MFC thing, so have re-posted it here.] I have a very strange problem with single-line edit controls in Windows 7 and Windows 2008 Server, where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear. I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog. I have also reproduced it in a new WFC app with a single-line edit control. I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there. (I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7). Does anyone have any ideas of what is going on? Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey -
Hi, [I have posted this already on the C/C++/MFC forum, but have since found that it is a Windows thing rather than a C/C++/MFC thing, so have re-posted it here.] I have a very strange problem with single-line edit controls in Windows 7 and Windows 2008 Server, where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear. I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog. I have also reproduced it in a new WFC app with a single-line edit control. I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there. (I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7). Does anyone have any ideas of what is going on? Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John DeweyI am using Win32 under Visual C++ 2010 Express on Windows 7. I just tried with W characters to an edit box in my test dialog and they did not disappear until the count got somewhere near 20,000+. I suspect it is something to do with the edit control's paint function getting messed up when the size gets too big, but not necessarily to do with the number of pixels. I would assume that the control will try to redraw its contents based on the current cursor position within the displayable portion of the control. Maybe Microsoft has some information on limitations of such things.
It's time for a new signature.
-
Hi, [I have posted this already on the C/C++/MFC forum, but have since found that it is a Windows thing rather than a C/C++/MFC thing, so have re-posted it here.] I have a very strange problem with single-line edit controls in Windows 7 and Windows 2008 Server, where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear. I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog. I have also reproduced it in a new WFC app with a single-line edit control. I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there. (I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7). Does anyone have any ideas of what is going on? Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John DeweyPaul Vickery wrote:
Does anyone have any ideas of what is going on?
Nope. Intriguing as it may seem, I fail to understand how you discover this and find it relevant. It isn't like your display is 40,000+ pixels wide, is it? And do you really expect your users to scroll horizontally through thousands of characters? FWIW: My guesses would include limitations/bugs in GDI/GDI+, in the way some Windows versions may try and delegate some drawing to the graphic processor, etc. There was a time, might still be true, that GDI/GDI+ had a lot of 16-bit limitations, however it never bothered me. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Paul Vickery wrote:
Does anyone have any ideas of what is going on?
Nope. Intriguing as it may seem, I fail to understand how you discover this and find it relevant. It isn't like your display is 40,000+ pixels wide, is it? And do you really expect your users to scroll horizontally through thousands of characters? FWIW: My guesses would include limitations/bugs in GDI/GDI+, in the way some Windows versions may try and delegate some drawing to the graphic processor, etc. There was a time, might still be true, that GDI/GDI+ had a lot of 16-bit limitations, however it never bothered me. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Thanks for your reply. It was found in a part of our app that allows the user to select a number of files in an explorer-type window, and then perform an action on them. The edit control is used as the user may wish to type the paths instead of picking them. The intention is not that the user then looks through the unmanagable list. I don't really see that it is that unusual to have an app do that kind of thing. Anyway, I now know that it is not something we are doing wrong, or can do differently (apart from use an different method of letting the users see what they've picked of course), so that will suffice for now.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey -
Thanks for your reply. It was found in a part of our app that allows the user to select a number of files in an explorer-type window, and then perform an action on them. The edit control is used as the user may wish to type the paths instead of picking them. The intention is not that the user then looks through the unmanagable list. I don't really see that it is that unusual to have an app do that kind of thing. Anyway, I now know that it is not something we are doing wrong, or can do differently (apart from use an different method of letting the users see what they've picked of course), so that will suffice for now.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John DeweyThanks. I probably would handle that differently, avoiding all long textboxes: with a single-line TextBox for entering one file name, an "Add" button, and a listbox for showing the current collection (possibly adding edit and delete functionality). But then it depends on the operations the user is expected to be able to do... :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.