Let''s say I have a some gui components: Component, FrameWindow, Button. The Component is the base class of FrameWindow and Button. The Component class is responsible for handing the hierarchy for the gui objects. However, I run into a snag. The Component class has methods for adding child components and setting the parent component. But I shouldn''t be able to add a FrameWindow object to a Button object, because that doesn''t make any sense. Is this a problem with the design of the hierachy? Or should I add special code for handling these cases? Any help greatly appreciated. Kory

quote:Original post by kspansel
Let''s say I have a some gui components: Component, FrameWindow, Button.

The Component is the base class of FrameWindow and Button. The Component class is responsible for handing the hierarchy for the gui objects. However, I run into a snag.

The Component class has methods for adding child components and setting the parent component. But I shouldn''t be able to add a FrameWindow object to a Button object, because that doesn''t make any sense. Is this a problem with the design of the hierachy? Or should I add special code for handling these cases?

Any help greatly appreciated.

Kory

easy.. make a parent object and a child object.

a dialog frame would be a parent object, all the objects inside are child types.

-eldee
;another space monkey;
[ Forced Evolution Studios ]

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Taharez: i think that your design is a good one, but it doesnt solve his initial problem (that i can see initially); because CGuiContainer derives from the same class that CGuiButton derives from.. which means that you can have buttons floating out in space (without a container), and containers "inside" buttons or whatnot... hard to explain but thats what i picture when i look at your diagram

-eldee
;another space monkey;
[ Forced Evolution Studios ]

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Taharez:

I like your approach, this is basically how I initially thought about doing it. I guess I sidetracked a bit in my design.

Is there any specific reason for having the CGUI class?

I was thinking that I could remove the CGUI class and move any event handling code to the CGUIObject class.

I think this would work well for my event model (Dispatcher/Listener)

Any comments?

Thanks,
Kory

I''ve been doing a GUI in OpenGL for this week, and here are some of my considerations:

An elementary object - element. In OpenGL it will represent a simple textured quad (or something else).
A window consists of 3 major elements - window working area, border and titlebar.

A titlebar, in step, consists of N elements (buttons) and a text and probably an icon.
A border consists of 8 elements - top, bottom, left, right, top left, top right, bottom left and bottom right rectangles.

Other elements such as buttons, static controls etc are derived from element class because they are simply an animated textured quad.

An element has also a linked list of sub-elements that can be added and removed dynamically at run-time.
It has some virtual functions (e.g OnMouseDown, OnMouseMove etc).

Above all stands a Window manager, that controls ALL windows and their sub-sub-(etc) elements.

That''s about it. I''m going to release my source on my webpage (link below) so everybody can take a look.


Good luck.

" Do we need us? "

Ionware Productions - Games and Game Tools Development