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, 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.

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.

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!

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.

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.

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.

rookie,

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