- // If we don't have this (call Default()), we don't paint the background properly.
- // If we do have this, we seem to overwrite enclosed controls.
- // Is it the WS_CLIPCHILDREN style that's causing the problems?
- // Probably - without this style, the background of the window will show through,
- // so the control doesn't have to paint it. The window background will always be
- // painted before all other controls, therefore there are no problems with
- // controls being hidden by the static box.
- // So, if we could specify wxCLIP_CHILDREN in window, or not, we could optimise painting better.
- // We would assume wxCLIP_CHILDREN in a frame and a scrolled window, but not in a panel.
- // Is this too platform-specific?? What else can we do? Not a lot, since we have to pass
- // this information from arbitrary wxWindow derivatives, and it depends on what you wish to
- // do with the windows.
- // Alternatively, just make sure that wxStaticBox is always at the back! There are probably
- // few other circumstances where it matters about child clipping. But what about painting onto
- // to panel, inside a groupbox? Doesn't appear, because the box wipes it out.
- wxWindow *parent = GetParent();
- if ( parent && parent->GetHWND() && (::GetWindowLong((HWND) parent->GetHWND(), GWL_STYLE) & WS_CLIPCHILDREN) )
- {
- // TODO: May in fact need to generate a paint event for inside this
- // control's rectangle, otherwise all controls are going to be clipped -
- // ugh.
- HBRUSH hBrush = ::CreateSolidBrush(PALETTERGB(GetBackgroundColour().Red(), GetBackgroundColour().Green(), GetBackgroundColour().Blue()));
- int mode = ::SetMapMode((HDC) event.GetDC()->GetHDC(), MM_TEXT);
-
- RECT rect;
-
- ::GetClientRect((HWND) GetHWND(), &rect);
- ::FillRect ((HDC) event.GetDC()->GetHDC(), &rect, hBrush);
- ::DeleteObject(hBrush);
- ::SetMapMode((HDC) event.GetDC()->GetHDC(), mode);
- }
- else
- Default();
-}
-
-long wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
-{
- // TODO: somehow, this has to accept mouse clicks in user interface edit mode,
- // but not otherwise. Only there is no longer a UI edit mode...
-
- // It worked before because the message could be processed if not in UI
- // edit mode. We have to find some way of distinguishing this.
- // Maybe this class can have an AcceptMouseEvents(bool) function; a sort of
- // kludge... or, we can search for an active event table entry that will
- // intercept mouse events, and if one exists (that isn't the default),
- // skip the code below. Too time consuming though.
- // Perhaps it's ok to do the default thing *anyway* because the title or edge
- // of the window may still be active!
-// if (nMsg == WM_NCHITTEST)
-// return Default();
-
- if (nMsg == WM_NCHITTEST)