Can't get more than 10000 controls in a panel

[ThatThatGuy]

This is an unsual and weird problem that im facing....

Im developing a ticketing software where ....

At runtime when i try to add more than 10000 labels in the panel for seat layouts...

the program raises a Win32 unhandled exception...

[Plater]

You may have surpased a hard limit. Can you even fit 10,000 labels on the screen at one time?

[tlhintoq]

Does the code work with 100 labels?

Otherwise post the relevant code where the exception occures

[ThatThatGuy]

the application is about seat layouts where....
at runtime the application accepts for the rows and cols for seats and draws...
them according.....

when i enter (90 rows and 90 cols) it draws them on Panel and the panel is scrollable...

but when i do (100 rows and 100 cols) it raises a Win32 exception and the error message displays is "Error creating Handle"....

[Plater]

Did you run in debug to see where the exception was being thrown at?

[GaryTexmo]

There's a built in limit to the number of window handles windows will give you. It's supposed to be in a per application basis, but there's some oddness in there. Google around with various keywords, there's some information/discussion you can find.

Also, to play around with this a while back I made a little handle tester. You're welcome to play around with it if you like, but use at your own risk :)

http://members.shaw.ca/gtexmo/Code/C%23/Misc/HandleTester/

(This is the code so you can see how things were handled, and how my program recovers from the error generated by hitting that control limit. Yea, it really feels like a hack, but it does the job. It was the only way I could find to recover... just trying to clear the panel controls would throw the exception again. I had to null the entire panel and regenerate, which felt really cumbersome.)

To resolve the issue, you have two options...

1) Handle the problem in a different way. You can either draw only the controls you could possibly see on the screen at any given time and then manually deal with scrolling, or you can change your data presentation entirely. I've seen a few suggestions on breaking the data up into categories, then displaying each category as requested. Caching helps with recall and can bump off unused categories to make room for new controls when they need to be allocated.

2) There is a registry entry you can use (again, search google) to bump up the number of window handles Windows will let you use. I'm not exactly sure on the details and I think it's still capped in some way, but it will let you exceed that 10k limit.

Personally, I'd say #1 is a better way to go even though it requires more work. I guess it depends on your deployment and if you can have access to this registry setting on your client machines. Also, ten thousand controls is a lot to process at any one time, breaking it down might increase the usability of your program. Of course, it is a lot easier to just change the registry setting.

Whatever works best for you :)

(Again though, I highly recommend doing some googling. This issue has quite a bit of information on it.)

[tlhintoq]

Handling the architecture differently is your best bet. For example: Instead of trying to load 10,000 seats, load 20 sections, then narrow to 1,000 seats per section.

Or load no seats at all: Load a graphic of the areana and calculate what seat was clicked on by mouse location... etc.

[ThatThatGuy]

i dropped the idea of drawing seat layouts with labels and
chose the GDI+ for drawing seat layouts...

thanx for your replies

[Studlyami]

The registry value needed to modify this value is located at

HKEY_LOCAL_MACH INE\SOFTWARE\Mi crosoft\Windows NT\CurrentVersi on\Windows\USER ProcessHandleQu ota

The limit is at 10000 by default (at least on my PC).

http://msdn.microsoft.com/en-us/library/ms725486(VS.85).aspx

[ThatThatGuy]

The registry value needed to modify this value is located at

HKEY_LOCAL_MACH INE\SOFTWARE\Mi crosoft\Windows NT\CurrentVersi on\Windows\USER ProcessHandleQu ota

The limit is at 10000 by default (at least on my PC).

http://msdn.microsoft.com/en-us/libr...86(VS.85).aspx

No Pal..... in my machine the limit was 2710.....
i changed it to 10000 but it didn't worked ......

[Studlyami]

Sorry to hear that. Did you try setting it higher like 15000 or 18000? It sounds like you already have a workable solution, but it would be interesting to know if a higher handle limit fixes the problem.

[ThatThatGuy]

Avoid too much flickering of GDI+ objects on scroll

hello.....

Im building a seat layout editor for a ticketing software
Where i need to provide the user to create unlimited or maximum 1.5 crore seats..... as told by my manager....

although it doesn't this application doesn't do well even when i add more than 200,000 seats....

and the seats are all GDI+ ellipses

and the seat layout is a user control and its inside a panel.....

so when the the panel is scrolled it the control happens to repaint.....
and all the seats are painted again.... it creates a slow processs....

and the UI performance is getting worse....

although ive done every thing like i ...... set the styles

this.SetStyle(C ontrolStyles.Al lPaintingInWmPa int, true);
this.SetStyle(C ontrolStyles.Op aque, true);
this.SetStyle(C ontrolStyles.Ca cheText, true);
this.SetStyle(C ontrolStyles.Re sizeRedraw, true);
this.SetStyle(C ontrolStyles.Us erPaint, true);


still it causes flickering... any answers would be appreciated....

[tlhintoq]

Your second post of this question (now with GDI+ ellipse) has been merged with the original thread for this problem.

If you didn't understand in the earlier posts let me try to rephrase:
It is totally unrealistic to add 200,000 controls to a panel. It doesn't matter what kind of controls you try to add whether they are button, picturebox, label, or ellipse. All of these are still derived from the base class of 'control'

Realistically, if this could be done don't you think the large ticket companies would already be doing it? You don't see this type of interface on Ticketmaster for a reason.

[ThatThatGuy]

No..... the fickering has stopped due to user32.dll's LockWindowUpdat e API..... and it's working fine with 200,000 .... the gdi+ ellipses do the thing....

But the problem now is can i zoom a part of the user control .... somehow


and i getting this bug for a ruler control when it's width exceeds 32767 px

[tlhintoq]

But the problem now is can i zoom a part of the user control .... somehow

So you did all this work... did all that coding for 200,000 ellipses on a panel... built all of this around a usercontrol and panel... Without knowing whether or not a usercontrol could do what you needed it to do (zoom)?

You did no small-scale test? Like draw one small ellipse and see if you could zoom in?

If you have no idea how you are going to fulfill a job contract then don't bid on it.