- // 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(GetHwndOf(parent), 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.
-
- // let wxControl::OnEraseBackground() do the job
- event.Skip();
- }
- //else: do *not* call event.Skip() or wxControl will erase the background