@UniTech -
AWESOME! (I'm glad you're back around!)
@Neils -
Absolutely <--Short Answer
Long answer?
The "GUI" has a lot of default values... for things like how big the "frame" is for a specific "WindowBorderStyle" ... It's frame TOP, frame Left, frame Right, frame Bottom thickness, and depending on widow style, the drawable CaptionSize, if a borderstyle that has captions, is configurable also. Also, there is a GUI "Global" Minimized Height, and Minimized Width (this width is calculated when you start the GUI class so that they can evenly fit across the display without gaps

)
Caption size controls the "drag" area where the mouse works for dragging. Frame Size, on sizable windows, effects the "mouse sizing" "Grab" regions. (8 per form, sides and corners)
But you can override the defaults, change the fonts, where the fonts show up, originate font from top/left coord you specify, or top/right (drawing to left) if you want...
The thing I'm going to do that kind of neat I think - (if anyone thinks it a bad idea - tell me) is that.
Normally in windows you get a paint even for the "Form" "user region" (the area in the form) and if you want, when controls are drawn.
I'm making events you can capture for "Each" piece of the drawing process, so you can "Wedge in" your own "Draw Caption" routine entirely! Or your own frame draw routine... entirely, or the background fill.. (that actually happens first) entirely... I keep saying entirely, because if you wish to "Consume the event" ... like drawing the caption area, you set the message type to ZERO after you are done drawing, then the GUI won't BOTHER to overwrite your work with its idea of how it should be because you effectively told it "I'm DRAWING IT MY WAY". I tried to make the properties for each "Drawing Element easy" to use and follow.
Here I use my JGC_TBLR (four values and width/height functions)to specify how "thick" each frame side is.
FrameThickness->Top
FrameThickness->Left
FrameThickness->Right
FrameThickness->Bottom
here I use the same base JGC_TBLR class to describe the actual coordinates of the "CAPTION DRAWING/DRAG AREA" So its Easy to Draw on the paint event for this "Drawing Element" because in theory - you have the exact pixels describing your chalk board - so to speak.
// int's
Caption->Top
Caption->Left
Caption->Right
Caption->Bottom
Also, don't forget, you can stay as close to stock as you want, or get really out there... its a gui engine of sorts made to be flexible with regards to display.
there of course has to be some rules... like everything needs to be drawn in the confines of the window Paintsize, but drawing "Out of bounds" doesn't cause an error (Pixel Grid handles that) But due to transparency, you can get nuts and make windows with a drag area thats floating above the window.. (in appearance) and you can let your imagination run wild.
MY goal is to provide a STANDARD reckognizable GUI interface - that WORKS... (So you have a solid starting point) with the ability to tweak to customize to taste.
After I finish the Cascade and Tile routines (I have an idea for cascade that should be more efficient than what I have working now... and it will behave hopefully pretty SPOT ON to how micrsoft does it (I look at Excel, with a ton of open "WorkBooks" to see how it does it. I like how it does it, and I want to mimic this)
Tiling Horizontal and Vertical I haven't even taken a stab at... but NEXT... Is some MODEL DIALOGS like Windows "Message Box" and I'm thinking about making them work like functions like they do normally in windows however I'd prefer to have it so the dialog can be on screen, modal, BUT... aloow your game engine to continue if you want... so animated models keep animating, and other stuff still seems to work "Behind" the dialog if that's what the "developer" wants it to do. (This doesn't at first glance seem to jive with a simple function call... I'lll figure something out.. maybe a system of hooks you can capture while the disloag is on screen - to snag its "user response" while your main loop keeps plugging away!
So... yeah, this gui should be very pliable. And the ULTIMATE CONTROL and redefinition of many rules Would be possible if I made a Hook to the "CalculateDimensions" routine that happens JUST BEFORE the actual under the hood PAINT routines, this way you could let the GUI "RULES" make their decisions, and then you could override them before the painting gets underway.
Thanx for asking. Boy, the designer is going to hard to make.... but it will be worth it I think!