• Advertisement
Sign in to follow this  

MFC won't let you create more than 10K objects

This topic is 4039 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, I have an MFC dlg app; when I try to create over 10K instances of child CWnd or CButtons the app won't respond correctly and I get the 'ping' sound as each of the subsequent child is created. The child messages wont get processed at all and the AfxMessageBox used on the parent level won't work. (edited) The total memory used was around 6M. How can I overcome this problem--want to create over 10K child objects? I would like to create child objects with message handling capability. Or perhaps I should use C# or Java. Are there limitations there also?

Share this post


Link to post
Share on other sites
Advertisement
10,000 child controls is massive; far more than you should need. Switching languages or APIs won't solve the issue.

What exactly are you doing?

Share this post


Link to post
Share on other sites
Stupid question on my part but, humor me if you would.

Why, do you wish to create over 10k child objects?

Share this post


Link to post
Share on other sites
To overcome this problem you should simply ask yourself why you would need 10k dialog elements. I doubt that any UI library would handle this amount of widgets, as the OS itself has a certain limit on window handles and other objects created for each instance.

So my question would be: what do you need 10k buttons/windows for?

Share this post


Link to post
Share on other sites
thanks for asking...

but sorry I cannot tell you why... perhaps in a few months.

Perhaps I can use threads. Are there limitations to that?

Can a simple class handle messages other than throw/catch.

Share this post


Link to post
Share on other sites
<offtopic>

My first year at DigiPen the game project was required to be text-based only.

One team did a 2D Final Fantasy-alike with sprite graphics (looked pretty good) by using GDI and drawing it using colored periods. The professor was pissed (though I think it was an act, it was too clever for him to not appreciate it).

Maybe this project is similar, but using all text boxes? [grin]

</offtopic>

Quote:
Perhaps I can use threads. Are there limitations to that?

The problem isn't that it's on one thread. Windows is not designed to have 10k window controls in the same program. I'm not sure that it could handle 10k window controls at the same time within all of the programs currently running combined.

You need some optimizing, theres no reason to ever need that many controls unless you are doing something really absurd.

Share this post


Link to post
Share on other sites
Well, it's not MFC, it's Windows. You can only have 10000 GDI handles per process. And this is for Windows NT. Earlier versions were limited even more. As others have stated, you probably need to rethink how you're accomplishing your task.

Share this post


Link to post
Share on other sites
sighhhhh ... hmmm

maybe I can just use files as ojects but this will be friggin slow.

Nothing obsurd... it's quite advanced ahead of the times (apparently for the OS's)

thanks all!


Share this post


Link to post
Share on other sites
Quote:

thanks for asking...

but sorry I cannot tell you why... perhaps in a few months.

You have no other option. You cannot have that many child windows. You shouldn't even have a quarter of that; there is no valid reason to.

If you're trying to implement a custom control with a complex UI, you may need to manually draw a lot of complexity yourself on a single control (I have to do this with a graph viewing control I implemented, for example), rather than rely on leveraging hundreds of child windows. That's the only way to do it if you want acceptable performance.

Rethink your design.

Quote:

it's quite advanced ahead of the times (apparently for the OS's)

While whatever you're implementing might be "advanced" and "ahead of the times," your proposed implementation is most certainly about twenty years behind the times. It's a bad design, which is why the OS makes it tough for you to implement.

Rethink your design.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by doanwon
thanks for asking...

but sorry I cannot tell you why... perhaps in a few months.

Perhaps I can use threads. Are there limitations to that?

Can a simple class handle messages other than throw/catch.


ROFL Thanks a lot. I just blew a latte all over my screen and keyboard. That's going to be a pain to clean.



Share this post


Link to post
Share on other sites
thanks...

you are right, what I am trying to do is not what the OS was desined for.

I think I need to write my own OS for what I am doing.

(edited) It's serious! Not intend to make you spill cofee.

Share this post


Link to post
Share on other sites
No, you don't.

I assure you you can implement whatever it is you're trying to represent with 10,000 controls in Windows. As I said, all you need to do is use one control. Since you're being so stubborn (likely naively, I might add) about revealing your idea, I'll explain to you using my previously cited example of a graph control.

I needed a control to provide a visual representation of a directed acyclic graph containing (potentially) large numbers of vertices (nodes). The control was to be used to build or add onto the graph, so each node had to appear to act like a little window within the graph control -- draggable, clickable, et cetera.

This was done with one single control/HWND. The GraphView class had a big list of all the "logical children" (the 10,000 child windows in your example, the graph vertices in mine). But only one actual HWND. When the HWND was repainted, the children would be manually redrawn with simple GDI commands (culling was used so that I only processed and painted the visible set of children, obviously).

Likewise, when deal with user input, I would trap the input from the main HWND and use simple logic to find out if the input or event happened to correspond to any of the logical children, and perform the appropriate actions such as moving or deleting the child/vertex et cetera.

It's not all that difficult a solution, and it should work for what you're doing.

Quote:

I think I need to write my own OS for what I am doing.

That is, quite frankly, ridiculous. All other issues aside, if you rebuilt your own OS, you know how you'd handle having 10,000 child controls? Exactly how I described handling in Windows. Except you'd have spent thousands of man-hours reimplementing a basic, stripped-down operating system to do it, and then nobody could use your brilliant new technology because nobody has your OS installed.

Share this post


Link to post
Share on other sites
hello jpetrie,

your comparison is very close. So the solution is to 'draw my own UI' as in you first post. I will have to rethink my design.

Rewriting OS was a thought because I have a SAMS book with CD codes ready.

Yes I am a little naive program-wise and perhaps otherwise.

Share this post


Link to post
Share on other sites
From your posts it seems like you're using this mostly, if not exclusively, for the message passing system... If that is the case, why not impliment your own messaging system, or use one of the existing, freely available solutions?

There's nothing magic about the Windows messaging system, other than that its tied into the OS. If you need to interact with the OS or other Apps some combination of IPC and/or a translation layer between your wndProc and your own messaging system should suffice. You can create a functional equivilant to the Windows Message System in a weekend tops (A good programmer with an idea what they're doing could do it in a few hours,) and it will be more tailored and optimized for your situation.


That being said, I think you most likely do have a poor design, as others have pointed out. Honestly, if it were the best solution someone smarter than you, I and 99% of other programmers would have thought of, and implimented, it already. There's a reason no one has.

Also, why do you have to keep your reasons so hush-hush? Its not like your idea is going to be so earth-shattering that everyone here will steal it and get rich... share your problem, rather than your symptoms, and we can help you find a solution.

Share this post


Link to post
Share on other sites
thanks pavyne,

yes one of the main reason for doing this is to use message handling. Will do search for available codes out there.

One reason for the hush-hush of my project is to keep peoples the latte where it belongs-- in the cup not on someones lap or the screen.

Thanks!

Share this post


Link to post
Share on other sites
The "redesign" you need is identical to the "Flyweight" design pattern ... in a case where you want to have MANY MANY MANY of an object and the cost to do so the naive way (instanciate a new instance of some thing for each one) is too costly to be performant, then you simple come up with an agregate object instead, which efficently acts as the manager of the data for the multiples.

Examples would be:

1. having a View class which manages its whole Device Context instead of a device context per object in the view.
2. having a ParticleSystem instead of instantiate objects per particle ...

you get the idea I hope.

Share this post


Link to post
Share on other sites
Xai,

this crossed my mind but the drawback for me is when the number of objects becomes large then the manager has to do a search on the data everytime it needs access. Perhaps a multistage manager is ok, too. Thanks.

Share this post


Link to post
Share on other sites
Ordering your objects (or keeping ordered references) might help with the searching problem. It is possible to create a pretty efficient search structure depending on your needs,like quad-trees.

Share this post


Link to post
Share on other sites
rookie,

at the moment I don't have a way to order or prearrange my objects because there is no order in them. Thanks.

Share this post


Link to post
Share on other sites
Is this a joke thread?

If not, just implement your own messaging system. Anything else is just making things hard on yourself.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
sorry for appearing as a joke thread.

I have already agreed with pavyne to implement my own messaging. I am just trying to learn by posting here. Without that I don't know if I would take this path...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by doanwon...Rewriting OS was a thought because I have a SAMS book with CD codes ready...


Thank God _I_ wasn't drinking a latte!

Share this post


Link to post
Share on other sites
Seriously, do you know how say, a spreadsheet program is implemented? You don't think it has one editbox per grid cell do you?! Hell No! It uses tricks to make you think that it does. You simply need to learn the same kind of tricks.

Share this post


Link to post
Share on other sites
Quote:
Original post by doanwon
thanks...

you are right, what I am trying to do is not what the OS was desined for.

I think I need to write my own OS for what I am doing.

(edited) It's serious! Not intend to make you spill cofee.


No offense intended, but do you understand what you wrote? You want to write another OS because Windows can't handle more than the 10K controls of your program?

Are you really serious? Are you really ready to spend 5 years to write a complete graphical OS just to be able to create 10k+ controls in ONE program?

Can't you just find another scheme to store your controls? You are obviously not displaying 10k controls (that would be a massive and unusable UI), so why can't you just find a way to create the controls you need when you need them, and destroy those which are no more visible?

UI objects are used to display controls, not to search or do whatever you want with them. They are a way to interact with a user. I personnally think you misunderstood something about UI programming - and I mean, something quite serious.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement