AuroraMiddleware/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fixed the bug with the order of 2 size events when the scrollbar[s] (dis)appear in wxScrolledWindow

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@11858 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin 2001-10-06 02:22:26 +00:00
parent 2aabc7da6a
commit ff18659103
1 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
src/generic/scrlwing.cpp
View File

@ -173,13 +173,6 @@ bool wxScrollHelperEvtHandler::ProcessEvent(wxEvent& event)
{
wxEventType evType = event.GetEventType();
// always process the size events ourselves, even if the user code handles
// them as well, as we need to AdjustScrollbars()
if ( evType == wxEVT_SIZE )
{
m_scrollHelper->HandleOnSize((wxSizeEvent &)event);
}
// the explanation of wxEVT_PAINT processing hack: for historic reasons
// there are 2 ways to process this event in classes deriving from
// wxScrolledWindow. The user code may
@ -198,7 +191,24 @@ bool wxScrollHelperEvtHandler::ProcessEvent(wxEvent& event)
// user code defined OnPaint() in the derived class)
m_hasDrawnWindow = TRUE;
if ( wxEvtHandler::ProcessEvent(event) )
// pass it on to the real handler
bool processed = wxEvtHandler::ProcessEvent(event);
// always process the size events ourselves, even if the user code handles
// them as well, as we need to AdjustScrollbars()
//
// NB: it is important to do it after processing the event in the normal
// way as HandleOnSize() may generate a wxEVT_SIZE itself if the
// scrollbar[s] (dis)appear and it should be seen by the user code
// after this one
if ( evType == wxEVT_SIZE )
{
m_scrollHelper->HandleOnSize((wxSizeEvent &)event);
return TRUE;
}
if ( processed )
{
// normally, nothing more to do here - except if it was a paint event
// which wasn't really processed, then we'll try to call our