Make overriding virtual methods more explicit and enable additional checks
provided by C++11 compilers when "override" is used.
Closes#16100.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76173 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Undo the change introduced, probably accidentally, by r11369 (12 years ago)
and skip the default handling of all events except wxEVT_SIZE and wxEVT_PAINT,
which are special for the reasons explained in the comments in the code, if
the user code has already handled the event.
This allows to customize scrolling by selectively handling some scrolling
events only and generally makes sense.
Closes#15684.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75252 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Factor out the keyboard handling code in wxAnyScrollHelperBase allowing its
reuse in wxVarScrollHelperEvtHandler.
Now wxVarScrollHelperBase handles cursor keys in a sane way by default
too and also allows disabling their handling, just as wxScrolledWindow.
See #15357.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74815 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Merge the fixes to wxScrollHelperBase::ProcessEvent() of r64358, r64370,
r64464, r72939 and possibly a few more in wxVarScrollHelperBase to fix its
behaviour too, as it wasn't generating the correct events any longer.
Unfortunately the fix right now is to physically copy the code from one class
to the other. This should be avoided, of course, and a more in depth
refactoring should be done to move the code common to both classes into
wxAnyScrollHelperBase after 3.0 release. But for now continuing to duplicate
code is better than not having a working wxVarScrollHelperBase.
See #15357.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74814 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is just a small refactoring to move some trivially common parts of
wxScrollHelperBase and wxVarScrollHelperBase in a new common base class.
This will make it possible to apply other corrections to wxVarScrollHelperBase
without having to physically duplicate the code from wxScrollHelperBase in it.
See #15357.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74813 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Override CanScroll() in wxScrolled to return the real state of the scrollbar
instead of just relying on the wx[HV]SCROLL styles.
Closes#15440.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74714 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
