MFC won't let you create more than 10K objects
Author
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?
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?
What exactly are you doing?
Stupid question on my part but, humor me if you would.
Why, do you wish to create over 10k child objects?
Why, do you wish to create over 10k child objects?
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?
So my question would be: what do you need 10k buttons/windows for?
Author
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.
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.
<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>
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.
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.
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.
Author
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!
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!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
