"natural" os windows

[fathom]

i see there’s a flag when adding a window to the desktop to give a window it’s natural titlebar for whatever window manager is running. but that doesn’t seem to have any bearing on the remainder of the window – it lacks borders, for example. is there another flag somewhere to add these?

also, the title bar has a tendency to be over drawn by whatever component is stored therein. i guess it’s up to the programmer to ensure that the titlebar area is safe from components? i’m using a resizableWindow with a component as the containerComponent and it defaults to leaving a thing border around all edges (ie, no room at the top).

i add my resizable window to the desktop (with the titlebar flag) before adding the container, so i would expect the container would know what my legit draw area is.

or am i doing things wrong? i’m new to both C++ and juce and i’ve already aborted a few posts after realizing i was doing things wrong or using the wrong components, so it could be me.

[jules]

I’ve not done any native window stuff yet, which explains why there’s no titlebar - sorry. It’s on my to-do list…

I’m probably going to do a more application-oriented window class soon, with a titlebar that’s got minimise/maximise buttons, etc. You could use a DialogWindow in the meantime.

[fathom]

wow. do i not understand windows’ window drawing system at ALL!

do you have draw this stuff (window frames, etc) by hand? i tied adding just about every flag i could think of to the createWindowEX styles and nothing seems to work.

i get a glimpse of a title bar (when the window is activated), but never any borders and that menu bar is never redrawn unless i stow and unstow the window.

i even disabled the DIB drawing (which seems to be where the juce stuff actually makes it to the screen) and all that happens is the juce stuff quits drawing – just wanted to verify stuff wasn’t being overwritten.

msdn is really good about forcing you to learn a whole subject before you can even tell if you’re in the right place.

[fathom]

i get it now. the default window message handling proc for WM_PAINT, etc is what draws this stuff. so instead of returning after catching a WM_PAINT message (and others) you need to break out of the switch statement and let the default proc get a go at it.

so borders now show up, but it throws off some drawing (and some cursor handling, too, which strikes me as a little strange for a drawing routine).

this has clearly moved into the “windows specific” arena, so i dunno if you’d like to move the thread over there.

[haydxn]

i just got confused myself with the ResizableWindow :hihi: i thought it was an enhanced DialogWindow with extra features for some reason… then i read the docs and saw that it’s the other way round!

i look forward to seeing an official juce ‘plainOldNormalWindowWithMinimiseAndMaximiseButtons’ component, but til then i guess i’ll make my own

@fathom - use DialogWindow instead of ResizableWindow and you’ll get a titlebar and a close button built in at the top, and your components won’t draw over them.