f you were to add an addChild() method to your EditorObject class which accepts another EditorObject, and if you were to maintain an actual list of children inside an EditorObject you could easily update your entire gui with only a single update call on the root widget. Within each update call in a widget you would traverse the list of children and do an update call on each of them individually, which gives you a nice recursive way of updating the gui.
Managing your gui in such a tree structure also makes your gui much easier to traverse from a programmer's point of view, as having access to a parent widget means having access to the entire subtree which that parent is root of.
I remain with my statement that using those super-methods is pretty much a hack.
[/quote]

I actually have a vector<EditorObject*> included to the EditorObject-class that I can add child objects too. I still felt like hardcoding certain consistant elements like the three buttons for the scrollbar makes things easier to work with. I'll have to overload the UpdateSuper()-method, but thats not a huge problem, since there is not such a huge amount of base objects derived from EditorObjects anymore after I got rid of the redundand ones..

Oh, by the way, I figured that what you mean that my update-method does is indeed the Update_Super-method, except I'm not passing the parents coordinates to the update-method but with SetSuperX() and SetSuperY(). Update_Super would just do the same thing for the (hard-coded) children.

Maybe I'm misinterpreting the way you use your update function in your gui elements, if that's the case just let me know. Right now, since I don't see any other way how you're updating your actual logic to manipulate your back-end data (eg. how does your scrollable window know that your scrollbar has been updated?), I'm assuming you're doing this in your update function.[/quote]

My windows knows about it from the return of Update(). If its true, it has been updated, So if m_pScrollbar()->Update() returns true, it calls m_pScrollbar->GetNowValue() to get the actual value and adjusts the content to that. It does that by setting the m_iOffSetX or Y variable, that is used in UpdateSuper() to set the according contents position.

If you wanted to do all of this purely with inheritance you'd have to create a button class which would handle this entire process in its update system. Also, if you wanted your button to be able to control and represent multiple sets of data at once you'd have to create a separate case for that as well, whereas MVC allows a single controller to manipulate and a single view to represent/observer multiple models.[/quote]

Well not quite, at least in my system. The Update()-method of the button determines its state: clicked, hold, hold+over, released, released+over (=activated). it returns true if any of these states apply, and the holding object then decides what to do with that, by checking if it has been activated. The object holding it might then call Down() to fix the button, Up() to release it and SetActive(bool) to make it unclickable/clickable. This is, example given, how I handle my tileset-toolbar right now:


EditorButton* pButton = m_pToolbar->GetActiveButton();
if(pButton == NULL || !pButton->Pressed() || !pButton->Over(Input::GetMousePos()))
return false;
switch(pButton->GetID())
{
case 0:
(*m_ppBrush)->SetErase();
break;
case 1:
{
pButton->Down();
PencilBrush* pPencilBrush = new PencilBrush(**m_ppBrush);
delete *m_ppBrush;
*m_ppBrush = pPencilBrush;
m_pToolbar->GetButton(2)->Up();
m_pToolbar->GetButton(3)->Up();
break;
}
case 2:
{
pButton->Down();
RectBrush* pRectBrush = new RectBrush(**m_ppBrush);
delete *m_ppBrush;
*m_ppBrush = pRectBrush;
m_pToolbar->GetButton(1)->Up();
m_pToolbar->GetButton(3)->Up();
break;
}
case 3:
{
pButton->Down();
BucketBrush* pBucketBrush = new BucketBrush(**m_ppBrush);
delete *m_ppBrush;
*m_ppBrush = pBucketBrush;
m_pToolbar->GetButton(1)->Up();
m_pToolbar->GetButton(2)->Up();
break;
}
}


So other then having that a case-statement and knowing the button by ID (it's not a big deal), I can just call new Toolbar, push back a few new buttons, and that code above is all I need to get it to work.

--- MVC-explanation ---

Ok, so I've read what you explained, and MVC definately sounds like a concept that does fit perfecly here. I don't know how I'd go about implementing it right now but thats maybe because I haven't worked with messaging-systems at all until now. But, before I go ahead and screw my current approach, I'd like to ask once again: Do I really get that much advantage of using it? Sorry, I don't mean to be annoying or anything, I just like to question things. There are many worst-case-scenarios you described, which happend to me in my first try on writing a map editor years ago. I've overused OOP to an extent that it wasn't workable with, like you described, and the whole thing wasn't even working well. It didn't have the featureset I already have by this time, though the older one took much longer to develop. Maybe I didn't emphasise that enough, but the current system works flawlessly, so I'm not asking for an alternative because my current approach is unworkable, no, it works so well that I'm looking for a way of making things even easier to work with. So, in a nutshell, here is how the whole update-routine works (or will work after I got rid of the EditorWindow-derived classes):

- Main frame calls Update() on all of its widgets
- Update() first sets traversal coordinates for all its children by calling UpdateSuper() (sry, I just realized how confiusing this may appeal. I'll try to improve it)
- next, Update()- all of the children
- If widget without children is hit: perform a self-update (e.g. button deciding what state is in)
- If widget was activated, return true, else false
- If Update()-returns true: set children as active, perform destinctive actions (eg. set offset variable when scrollbar has changed), skip other children and self-update, else proceed

So now at this point I'm not sure how to proceed. Thinking about it, isn't that almost what MVC tells? Except that I don't let an extern controller regulate the basic actions like a button being clicked, but.. whats the point here? Every button will work the same so why would I want an extern button-controller when I can simply let the button handle itself? And again, I'm not talking about how the button manipulates that data, I'm just talking about the buttons states. But hold onm a second. Say if I where to make my widgets able of registering a controller, to that the button sends the information that it was activated, and let that controller decide how to manipulate the back-end data. Wouldn't that be almost what you were talking about? That would be my plan for now, composing the destinctive windows (tileset,tilemap), out of one or more widgets, having a controller, registering that controller to the widget and having it send information back to the controller. How does that sound, in combination with my above update procedure?

That's basically the concept of using a controller yes, the button does not need to know what kind of controller it's maintaining, only that it is a controller, so any type of controller which could control any kind of model could be assigned to this button.[/quote]

So I'd design a generic controller interface, but how would I go about sending messages to it? My first intuitive would be to write different generic message-method like button_clicked, scrollbar_moved, and overload these, but it sounds again a little messy. Maybe a general send_message()-method where I pass information on what type of object sent it? Or anything completely different? Before stepping ahead and starting implenting it, I want to make sure. And I do inherit from the generic controller for the certain use purposes, right, or is there still something different to it?

In this case a window must explicitly know that it has a scrollbar which is manipulating it, which is not something you want in a flexible gui. What if you wanted to add a button to your window which scrolled down to a certain piece of content? With this method the window object would now also have to poll this button on each update to see whether it was clicked and update itself accordingly. Doesn't sound all too flexible, does it?
[/quote]


Flexibility wasn't my main purpose. Aside of my design flaws, I just made some deliberate simplifications as e.g. every window has two scrollbars (which might there or not) and a toolbar, etc.. well while I'm at it I might make it more flexible as well.

The same applies for the toolbar example you gave. Adding a button to the toolbar would require you to go in and edit the toolbar code to allow this new button to perform a certain task. With MVC you can add any generic button to any generic toolbar, and you can register a specific controller to that new button which completely defines its behaviour. No need to go in and edit your classes each time you want to add a certain bit of functionality for a specific use case.
[/quote]


Not quite, as in the code I posted above (it's in the redundand WindowTileset-class but still) the button actions are handled, and my toolbar stores a vector<EditorButton*>, so all I'd really have to do is change that type of code. But since I might want to add other objects to the toolbar as well, I should make it more general, too.

This is a design flaw, and hardcoding everything in and making these objects which are supposed to be decoupled from one another explicitly know about eachother is not a solution. In the case of a bad design you should modify your design to something that is extensible and which works without hacks instead of adding more hacks to make the original design work.
Some form of messaging will be required eventually in a GUI system, so better to design it properly now instead of having to go back and adjust your design later on. MVC can provide a solution here since broadcasting of state changes and events is automatically implied as soon as one occurs.[/quote]

Ah, I slowly realize how much neater to work such a generic system was. Ok, so what if I made this:

- First, i call MainFrame->Update(). Update() now doesn't do anything more than traverse all the child objects, and so on.
- If the main controller receives any event (mouse-move, mouse-click) it will check recursively if an widget is underneath the mouse OR marked active (if I e.g. clicked on a button and hold the mouse, I don't want anything else happen unless the mouse is released, and even if it is, the release-message should still be sent to the button original held. Do I really need to keep like a extra pointer if an object is active and check that first, or is there any way to automatice that?) and send a message to the widget, like onClick(). (By the way, can I just send messages as a method, so therefore call m_vObjects[X].onClick() or do I need to use some more abstrusive design?)
- The object, eg. button does all self-management it needs (changing texture to represent pressed state, etc..) and then sents the controller an onClick()-message -> see question at the top.

Sounds good, at least to me. Well I'd be glad if you could explain to me how I should communicate with the controller, other than that I think I'll go that route, shouldn't I?

What I don't favor is putting bunch of variables that are sprawling over the place inside the Widget class, when they can be split up and contained in their own classes or structures, which you can then use with more flexibility. For example, width, height and X and Y position can be stored in a Rectangle structure. The extent to how you define the visual appearance is up to you. Do you want the UI system to use one skin, or maybe give the ability to mix several skins, with some taking priority over the "default" skin? Whatever the case may be, this should be separate from the classes that define behavior.[/quote]

Ok, I agree, I might want to put x, y, width and height into some sort of structure. Talking about the skin, I was just passing a texture pointer to the element, that represented the skin. Having the UI system itself handling the skins seems like a good idea, though. Didn't think about that.

Also, you have to see what makes each widget fundamentally unique. What makes a button a button? It's certainly not its size and position because all widgets have those. A button, like all other UI elements, is defined by its behavior. The Button class need not know it's position, just whether it's been clicked on, or not, and if clicked, trigger an event that would be passed up to the UI system to get the proper response.[/quote]

So you are talking about the button as being just the controller talking about MVC, right? Ah, I think I get it. Does that mean I'd have my baseclass EditorObject, which acts as a view, and can hold various amounts of controllers as well as the model. It accepts user inputs, but only redirects them to the controllers, which themself change the data in the model. So a button would be a normal Widget with a special controller that handles the button-specific tasks. Right? My head slowly starts to ache

One thing that I, however, really don't understand, is what the model exactly is. Is it some sort of template, or a certain data type that i define for each widget? Or is it like the buttons back-texture and image/text?

@Radikalizm:

One example of communicating with a controller is letting a widget maintain a list of controllers. When an onClick event occurs (so your button's onClick() method is called) for example you could iterate over your list of controllers and notify each of them that they should perform their designated action. This will automatically start the chain reaction of updating both model and view.[/quote]

Ok, that seems legit, but what I meant more specifically is how exactly do I tell the controller what exactly happend? Should I maintain a notify function for all widgets possible actions, like onButtonClick()?


At that point, though I think I still need a bit more, I want to thank you guys already for your help. I'll wait for your next answers, in the meanwhile I'll try to pseudo-code what I think this should look like..

I wouldn't do that, generally the view allows the controller to register "events", the view doesn't know about the controller directly.[/quote]

How would I do that? I can think about it using function pointers, but this whole topic is new to me so I'd rather go with registering the controller directely, unless there is some huge drawback.

If possible, use a windowing library, what you are doing here is trying to reinvent the wheel.

[/quote]

I really don't want to do that, as I'd like to get an understanding of how things work under the hood. You may call it a waste of time but I've learned quite a much only the last 24 hours, which might become usefull again later on.

Well, I think what you want to do is build your own gui framework. This means you build templates for the View. Templates for any controller / model is not a task of the windowing library afaik.
This means for the windowing library you need a class design for your gui elements and a messaging system, implementing the MVC pattern is not up to the library.
[/quote]

Still, I need some basic implentation of a model, right? I've implemented the basics of this, and it really is much easier and cleaner then my last approach, but.. what about the model? Is it really a class like this:


class Model
{
Model();
virtual ~Model();

protected:
int m_X, m_Y, m_Width, m_iHeight;
}


That like here holds the position and size of the widget, and from which I inherit in every special use case? Please, I'd really need an answer here. I've searched high and low but couldn't find a single example mentioning a concrete example of the model for that use case.