Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 355
  • Last Modified:

TComboBox limitation under Windows 7 vs XP

Hi,

I made a simple Delphi 2006 application with only a TComboBox component.  When I populate the Text property with more than 37,443 characters, the characters are not visible in the ComboBox when I run the program under Windows 7. The characters are there because I can copy them to the clipboard, but I can't see them.. There is no such limitation when I run the same program under Windows XP. Any number of characters less than or equal to 37,443 show up under Windows 7.

My question is, what should I do to my program to make the characters visible under Windows 7?

Regards,

Bill
0
wipnav
Asked:
wipnav
  • 6
  • 4
  • 4
  • +1
1 Solution
 
jimyXCommented:
Using Delphi 7 and Win 7, I have just verified that. There is no such limitation. So it's not the Windows.

Did you try to reproduce this issue in different case?

Ok let's try a clean code:
Drop two Buttons, Memo and ComboBox, use the following code as test case.

var
  Form1: TForm1;
  StrArr : array [1..26+26] of string = ('a','b','c','d','e','f','g','h','i','i','k','l','m','n','o','p','q',
  'r','s','t','u','v','w','x','y','z','A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T',
  'U','V','W','X','Y','Z');

implementation

uses StrUtils;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  i : integer;
  str : string;
begin
  for i:= 1 to 40000 do  // you might increase for more chars testing
    str:= str+RandomFrom(StrArr);  // unit StrUtils

  ComboBox1.Text := str;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  Memo1.Text := ComboBox1.Text;
  showmessage(inttostr(length(memo1.text)));
end;

Open in new window

0
 
wipnavAuthor Commented:
Thank you.

I used your exact code and it worked, just like it did for you.

Then I made a one line change (see below) to your code, and I don't see the characters in the ComboBox.

StrArr : array [1..1] of string = ('A');   // Only display A's
0
 
jimyXCommented:
I see what you mean now, it happens in Win XP and Win 8 as well. Even by using Delphi XE.

Seems like it is the limitation of the capacity of the ComboBox display canvas. And it seems like there is a limit for drawing the text in the ComboBox at different rate with respect to each character's width. For instance it takes 37440 A's and after inserting four more A's from the keyboard the text disappears. But it takes 29120 M's and after three M's from the keyboard the text disappears. And when trying with the tiniest char "I" it takes 43679 I's but strangely it does not accept to add (to the visible text) any more chars but when copying the ComboBox text to the Memo all the chars entered beyond the limits, were actually assigned to the text.

That explains why by combining different characters it managed to add above the 40000 chars.
37441 A
29121 M
43679 I

A curious question why do you need to reach that huge line of text in ComboBox anyway?

If it's not that necessary, as an idea, you could shrink the line and assign dots "..." to represent unterminated line but at least you are showing a big chunk of the text. If the user needs to see the full text give an option to view the content in a memo. We all do not want a complaining client of a crashing application ;)
0
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
wipnavAuthor Commented:
Thank you again.

I have an application written in Delphi 2006, that has been running under Windows XP for several years. I do not see this problem with XP, even with hundreds of thousands of characters in the ComboBox. Recently I moved it to Windows 7, and saw this issue. This application deals with very large datasets, and it is not uncommon for users to have tens of thousands of characters in the ComboBox. They are actually selecting items from a report, and they appear as comma separated values in the ComboBox (i.e., fjdskfj,34r34,4thgtr,rhrthtr,34343,...). Sometimes they might copy them from there, so I can't truncate the list and add [...].

I'm not sure why this isn't working for you under XP, when it works for me. in my mind, if it works under XP, there should be something that can be set in Windows 7 to get it to work.
0
 
Sinisa VukCommented:
It is good to limit user input by setting MaxLength (Edit, ComboBox,...).
And use char filtering too - to avoid possible problems when inserting to database.
0
 
jimyXCommented:
>   I'm not sure why this isn't working for you under XP, when it works for me
Was it 32 or 64 bit Xp?

>   there should be something that can be set in Windows 7 to get it to work.
You have limited Text Buffer, it is always the case, resources are supposed to be limited. MS says it's 32KB buffer limit and to increase you need to allocate the memory and do the under-the-hood work for the control yourself.

Here is an interesting link to read about the text buffer and the EN_ERRSPACE message that causes the ComboBox to crash.

Although it's explained how to obtain a new buffer using LocalAlloc to accommodate your text, I am sure you know the implication of this.
0
 
wipnavAuthor Commented:
It was 32 bit XP.

The issue isn't with the size of the text buffer. It holds all of the characters. I can enter lots of characters. I just can't see them once I exceed the limit I mentioned previously. The characters are just invisible under Windows 7, but visible under 32 bit XP.
0
 
Geert GOracle dbaCommented:
damn... you'r right, nice bug !

the simplest code to test the bug
uses StrUtils;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ComboBox1.Text := DupeString('M', 40000);
end;

Open in new window

0
 
wipnavAuthor Commented:
Thank you. We have a nice bug, and a simple test case. All we need now is a fix.
0
 
Geert GOracle dbaCommented:
edit has it too
Edit1.Text := DupeString('M', 40000);

aaaahhhh ... it 's a microsoft limit
check this:
http://msdn.microsoft.com/en-us/library/ms997530.aspx

Limits of Edit Controls

Edit controls were designed to enter, display, and edit small amounts of text. They were not meant to be the basis for large-scale text editors. Edit controls in Microsoft® Windows™ have the following limits:

    Single-line edit controls are limited to a maximum of 32K (32,767 bytes) of text and, of course, to a single line. By default, single-line edit controls are limited to 30,000 characters. An application can change this limit to a maximum of 32,767 characters with the EM_LIMITTEXT message described in "Edit Control Messages," later in this article.
    Multiple-line edit controls are limited to a maximum of 64K (65,535 bytes) of text. Whether a multiple-line edit control is actually able to approach this limit is based on how the edit control uses memory. Techniques to control the way edit controls use memory are described in the next section, "Edit Controls and Memory." Multiple-line edit controls are also limited to the following:
        characters per line of text
        lines of text
        pixels per line of text

Open in new window


the users i work with usually don't go past 200 characters in a single line edit
some exceptions are possible ...
0
 
Geert GOracle dbaCommented:
it's not really a bug ...
why would you want to edit 40000 M's on a line

use a memo or richedit

i'd bet my hat on it, that you'll never get a fix from Microsoft or Emabarcadero
They'll answer that 32000 characters is a reasonable limit to have on 1 line
Which i'd agree with

besides ... i don't have a hat
0
 
wipnavAuthor Commented:
That article was written in 1992, and references Windows 3.1. I can believe that there was such a limit back in the 20th century, but let's get with the times.

In any case, the control (ComboBox or Edit) works fine with more than 32,767 bytes.  I just tested DupeString('.', 40000), and no problem with Windows 7. I just tested DupeString('.', 400000) with XP, and no problem. That's 400 thousand characters with 32 bit XP.

If that isn't proof enough that this isn't a byte count issue, why does the behavior depend on which characters are used? There is something going on in 7 with the rendering of the characters.

In terms of my application, people don't edit lots of M's. This is just a simple test case that shows the bug. I'm not going to go into why the ComboBox ends up with large amounts of data, but there is a good reason for it, and it has worked very well over the past seven years or so.
0
 
Geert GOracle dbaCommented:
this will only be solved by emabarcadero or microsoft

you'll have to file a service request with either or both of those companies to get a fix
0
 
wipnavAuthor Commented:
Thank you all for trying to help with this issue.
0
 
jimyXCommented:
mlmcc, have you read the entire thread or you just started reading from bottom?
Did you see this comment?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 4
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now