ScrollPane

The newest SVN version has scrollbars and a scroll pane now, but from what I see, they are not ready yet, right?

Anyway, this version needs a few fixed. The implementation of the destructors of VerticalScrollBar and HorizontalScrollBar are missing and one cpp file ended up in the include directory. Does this even link on VC? It shouldn't.

Sorry.. yesterday was a long day, and my brain wasn't really functioning the whole time. I'm still trying to figure out how I want to implement scroll bars. I have made the fixes and committed to SVN.

An important change I have made is the separation of TrackBar into "HorizontalTrackBar" and "VerticalTrackBar". The ScrollBars will be separate too, and inherit from the TrackBar classes. I tried to make it so that there was a Layout option, and you could toggle horizontal or vertical after creation, but it quickly became a nightmare. I'm considering shortening the name to VScrollBar and HScrollBar, but I'm undecided. It's a long name as it is, but I have auto complete, and eventually there will be an editor so it won't matter..

On a side note, I have a question for you. I have 2 classes, QuadContainer and ScrollPane. A Panel IS a QuadContainer and IS a ScrollPane. But both of these classes need access to their owner widget. (their constructors take a pointer to the owner) I am getting a warning because I call the constructor with a pointer to this, in the default initialization of the Panel.

ie.

Panel(arg1,arg2,....,argn) :
Widget(...),
QuadContainer(this),
ScrollPane(this),


The compiler doesn't like "this" used in the default init phase, which is understandtable, since I'm defining what "this" is at that time. The only alternative I can think of is to make the classes have a default constructor, with some sort of "setup" function, that takes a pointer to the owner. These classes will not be used by users, only internally. Any suggestions?

I am fine with the longer class names (even though I am not using auto-completion). Regarding your question, that is a bit tricky. I need some more time to think about it.
At least VC produced a warning here. So it is probably not that sloppy after all.

I'm at work now, so I can't check, but I wonder if QuadContainer is expecting a pointer to a Panel. I don't remember my usage inside QuadContainer, but I might be able to work with a Widget*, and not Panel*. (Assuming it is asking for Panel*)

(current design idea..)
The reason for ScrollPane to have a handle to its owner is because the ScrollPane is the only object that will have ScrollBars. Since ScrollBar is a widget, I need to add it to a widget. (ScrollPane is not a widget, so I will have the owner be set as the parent to the ScrollBars, to maintain relative dimensions, etc.) In the end, I want to be able to have Panel, List, and MultiLineTextBox, etc inherit from ScrollPane, and be able to make use of ScrollBars.

Personally I would consider inheriting Panel from QuadContainer a rather questionable design. As far as I can see you are using the QuadContainer only to implement the Panel (though I haven't examined all the code). A Panel is not really a QuadContainer. Rather the QuadContainer. is an implementation detail of the Panel. Composition would be more appropriate here than inheritance. But if that fixes the problem or not would require another evaluation (I am not that familiar with the internals of QuickGUI after all and I am not in favour of another major redesign anyway).

Assuming we are sticking with the current design:
From what I see you are using the not fully constructed parent widget in the QuadContainer (i.e. you are not only storing the pointer). So there is really no chance, we can get this to work in the constructor.

The setup variant might be an option, if the class is used only internally. I would make the setup method and the parent-widget-less constructor of QuadContainer protected then. And I would carefully examine, if these constructors contain any virtual method calls, because that can cause serious problems. But honestly, the whole thing looks rather fishy.

Passing the this pointer itself should be safe (I am not 100% what the standard says about this, but I wouldn't expect any problems as long as you are not dereferencing the widget pointer in the QuadContainer's constructor.

From what I see you are doing the following in the QuadContainer's constructor:
- store the widget pointer (twice)
- call the getQuadContainer method of the parent widget to get the parent container (which never changes over the whole lifetime of the QuadContainer)
- call the getInstanceName method of the parent widget to get an ID (which never changes over the whole lifetime of the QuadContainer either)

The first operation should be safe, the other two aren't.

So, what you could do, is remove the mID and the mParentContainer data members from QuadContainer. Replace them with methods which query the parent widget. This way you have moved all questionable method calls out of the constructor and you don't need a setup method either.
It won't stop VC from emitting the warning, but that would be a false positive only.

Edit: The QuadContainer expects a Widget pointer, but that isn't really relevant here.

Edit2: I was confusing Panel and Pane in the first paragraph. Corrected now.

Thanks for the input.

As far as I can see you are using the QuadContainer only to implement the Panel (though I haven't examined all the code).

QuadContainers are QuickGUI's method to rendering Quads. They contain and manage a QuickGUI VertexBuffer. The QuadContainer also organizes the order in which quads are rendered, and can contain other QuadContainers. Render order:

1. Child Quads, sorted by Offset. (Offset is my equivalent to zOrder)
2. Panels, as QuadContainers. (List of QuadContainers)
3. Windows, as QuadContainers. (List of QuadContainers)
4. Menu Quads, sorted by Offset.

Additionally I have 2 layers, LAYER_CHILD and LAYER_MENU, so widgets can move between lists. Also note that only Sheets will make use of the Window QuadContainer list, as other widgets cannot create Windows.