Just always call the virtual OnDraw() if wxEVT_PAINT wasn't handled. This is
much simpler than connecting our own special handler just to set a flag saying
whether the event was processed which was very complicated and didn't work
anyhow for the statically connected wxEVT_PAINT handlers.
See #14757.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72939 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
SetScrollbars() passed its input positions expressed in scroll units to
CalcUnscrolledPosition() which takes positions in pixels. This was definitely
wrong so don't do this and perform the conversion from scroll units to pixels
in SetScrollbars() itself for clarity instead.
It's not clear what concrete bugs, if any, does this fix as the calculated
positions are almost never used anyhow but the old code was obviously
incorrect and the new version has a chance of not being wrong so it's already
an improvement.
Closes#9988.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70443 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The changes of r58323 ("Restore keyboard navi") fixed the handling of cursor
keys in the generic wxListCtrl implementation but at the price of not sending
keyboard events for the cursor keys to wxListCtrl itself any more. This made
it impossible to override their handling in user code, something that used to
work in previous wx versions and still works in wxMSW.
Revert the changes of this revision now and fix the original code by simply
disabling the handling of the cursor keys in wxScrollHelperBase using a newly
added DisableKeyboardScrolling() method. This ensures that the keyboard events
for cursor keys are not used to scroll the window when they are forwarded to
wxListCtrl from wxListMainWindow.
The fix is conceptually ugly as it would be better to avoid the need for such
ad hoc functions as DisableKeyboardScrolling() but it is very simple and there
just doesn't seem to be any sane way to do it otherwise with wxScrollHelperBase.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64877 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxDELETE[A]() functions which automatically NULL out their arguments after
deleting them instead of doing it manually.
Closes#9685.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64656 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
After the recent changes to the event processing logic, forwarding an event
from one event handler to another one stopped working correctly because the
per-event "process here only" flag prevented it from following the event
handler chain after forwarding. This notably broke keyboard navigation in
wxComboCtrl under MSW in wx itself and probably quite a few of other things in
user code.
Fix this by replacing the boolean flag with a pointer to the handler to which
the processing of this event should be restricted. This allows the full
processing to still take place if an event is forwarded to another handler.
So wxEvent::ShouldProcessHereOnly() is now called ShouldProcessOnlyIn() and
takes a wxEvtHandler parameter.
This made appear a problem in wxScrollHelperEvtHandler code that was hidden by
the bug above: the events were still processed multiple times in it. To fix
this, also add wxEvent::DidntHonourProcessOnlyIn() and take it into account in
the base class code. Did I mention that wxScrollHelperEvtHandler must die?
Add another unit test checking that forwarding works correctly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64464 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling ProcessEventLocally() didn't work because the command events were not
propagated to the parent window any more, breaking a lot of things including
wxDataViewCtrl event generation in the generic version. So do restore
ProcessEvent() call but use it on the next handler (i.e. the window itself)
and not this one now. This still results in some duplicate calls but at least
the events should be passed everywhere where they are expected to arrive.
wxScrollHelperEvtHandler must die.
Closes#12078.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64370 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use ProcessEventLocally() added in r64261 (which was probably the one to break
this) to forward event to the window itself instead of ProcessEvent() in
wxScrollHelperEvtHandler::ProcessEvent() implementation. Calling ProcessEvent()
didn't work any more in a case when another event handler was pushed on a
wxScrolledWindow: in this case the EVT_SIZE and EVT_PAINT handlers defined in
the window itself were not called at all any more.
Add a unit test checking for the even more tortuous than usual event
processing path in this particular case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64358 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't duplicate the existing wxScrolledWindow::CalcScrollInc() logic in
HandleOnChar(), simply generate scrolling events from it, this simplifies the
code and ensures that it is more correct.
Closes#11070.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61614 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
anything (typically wxPanel or wxWindow). Fixed generic wxListCtrl to
use wxScrolled<wxWindow> - this fixes focus problems with label-editing
text control. Fixes to wxScrolledWindow doxygen docs.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52961 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
if scrollbars disappear (instead of 1) as per wxMSW.
Expose m_x/yScrollLines in public getters.
Correct window origin for scrolled window in RTL.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@41186 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775