With ISA inheritance you''re saying that clients of your derived class expect to send msgs to it just the same as they would to the base class. You''re not going to tell them not to call certain class functions. KINDOF extends this by saying that not only do all the base methods apply to the derived but that new methods specific to the derived class can be added to it as well. With ISA you are allowed to override polymorphically base class methods. There is also private inheritance in case you need to inherit implementation but don''t want to expose the interface thru the derived object. The thing about inheritance is that child objects depend on the parent. You change something in the parent the child also has to change so people recommend all base members be private to keep them in the base class. The code reuse is not the important goal of OO. OO is about modeling behaviors and relationships among objects.

I know next to nothing about how to write gui frameworks. I think they use tree data structure to maintain sibling and parent to child relationships as well as z-order. There is also the issue of event handlers. Fox toolkit has good info on these details if you''re interested. But you probably just want something simpler in that case this website has a how to write a gui article using ddraw? I forget now. On dx forums section here there''s a guy doing a gui as well and he provides source code too. Check him out.

Might also want to check out design patterns for some ideas. Allen Holub dislikes model view controller system because it''s procedural way of doing things ie. not OO. Meaning views are pulling data out of docs. What I do is I pass view into the docs and have my objects render on the view. Having each object being responsible for its own brushes/pens and such and abstracting the way it draws itself has been better as task is centralized in one place ie. the object that manipulates its data. So you don''t have to pull data out and it reduces coupling among objects as the view can be a MFC CDC object so you don''t even have to know anything about the view. I do this with my grid view but I also use finite state machines ie. the taskmaster pattern to handle the user interaction logic. Though, it''s not entirely ok because input event logic is in fsm not the grid object. My idea was to separate the input from the grid drawing since I plan to reuse grid in another app and that one might use different input keys to do its thing. So the logic stays in fsm separate from grid object. A trade off I guess. There are bunch of these tradeoffs in a given design so the only reasonable way to know if you''re making sense is to adhere to common design principles and rules like ISA.