Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

1. undid my wrong fix to wxWindowBase::Centre

Browse Source 
2. corrected fatal bug in wxCheckLstBox (double deletion of items)
3. wxTextCtrl::SetValue() only does it if the new text is different from
   the old one
4. wxBitmap(const wxIcon&) ctor added
5. compilation fixes for VC++ and generic Win32 implementation of
   wxGetCurrentTime() in timercmn.cpp


git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4534 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
1999-11-13 00:30:45 +00:00
parent fd69e87d25
commit 07cf98cb8e
10 changed files with 113 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
src/msw/statbox.cpp
View File

@@ -114,47 +114,16 @@ WXHBRUSH wxStaticBox::OnCtlColor(WXHDC pDC, WXHWND pWnd, WXUINT nCtlColor,
::SetBkColor(hdc, wxColourToRGB(colBack));
::SetTextColor(hdc, wxColourToRGB(GetForegroundColour()));
wxBrush *brush= wxTheBrushList->FindOrCreateBrush(colBack, wxSOLID);
wxBrush *brush = wxTheBrushList->FindOrCreateBrush(colBack, wxSOLID);
return (WXHBRUSH)brush->GetResourceHandle();
}
// VZ: this is probably the most commented function in wxWindows, but I still
// don't understand what it does and why. Wouldn't it be better to _never_
// erase the background here? What would we lose if we didn't do it?
// (FIXME)
// Shouldn't erase the whole window, since the static box must only paint its
// outline.
void wxStaticBox::OnEraseBackground(wxEraseEvent& event)
{
// 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
// do nothing - the aim of having this function is to prevent
// wxControl::OnEraseBackground() to paint over the control inside the
// static box
}
long wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)