[ wxwindows-Patches-1671181 ] Updated wx[H/V/HV]ScrolledWindow
Refactor w/ AutoScroll
SourceForge.net
noreply at sourceforge.net
Sun Apr 1 07:38:34 PDT 2007
Patches item #1671181, was opened at 2007-02-28 21:07
Message generated for change (Comment added) made by vadz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1671181&group_id=9863
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Generic
Group: new feature
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Bryan Petty (bpetty)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updated wx[H/V/HV]ScrolledWindow Refactor w/ AutoScroll
Initial Comment:
Attached is an updated version of the wxVScrolledWindow refactoring (#1489165 [1]) with the addition of the wxHScrolledWindow and wxHVScrolledWindow classes. This patch has been split from the original refactored wx[H/V/HV]ScrolledWindow to avoid confusion of patch files and versions.
[1] http://urlx.org/sourceforge.net/3c30d
Older relevant patch (#1415017):
http://urlx.org/sourceforge.net/10958
Related wx-dev discussions (in order of date):
1. wxHVScrolledWindow patch (re: bugfixes needing merged)
>>>> http://urlx.org/thread.gmane.org/adfac
2. removing wxHVScrolledWindow
>>>> http://urlx.org/thread.gmane.org/6654d
3. wxHVScrolledWindow::Layout question
>>>> http://urlx.org/thread.gmane.org/bf7ca
4. wxHVScrolledWindow patch reverted
>>>> http://urlx.org/thread.gmane.org/a1349
The following updates/changes have been made:
== 1. Class hierarchy now outlined in include/wx/vscroll.h (enjoy the ASCII art). :)
== 2. Fixed HitTest() ambiguation bug. This was a previously unseen bug, first fix introduced with this patch.
== 3. Added some new wxVSPosition operator overloads. I agree that wxVSPosition should be moved to a wxPosition class and wxGridBagSizer updated to use that instead of wxGBPosition, but didn't have the time to do this myself.
== 4. Merged wxMac window update fix (previously applied to wxVScrolledWindow in CVS) into all scrolled window classes.
== 5. Updated in-source wxHScrolledWindow overview comments (they no longer describe wxVScrolledWindow). :)
== 6. Merged the committed wxScrollHelperEvtHandler::ProcessEvent() fixes discussed on wx-dev [2] into wxVarScrollHelperEvtHandler::ProcessEvent().
[2] http://urlx.org/thread.gmane.org/75443
== 7. Merged patch #1667599 [3] (Fix for wxVScrolledWindow SetLineCount() Repaint) to wxVarScrollHelperBase even though it hasn't been committed to CVS yet as I feel fairly confident about it, and don't want to need to update this patch later. I will revert and update this patch if patch #1667599 is rejected.
[3] http://urlx.org/sourceforge.net/6de5e
== 8. The biggest change as requested (and as I had wanted myself): Autoscroll has been broken out into a separate class (and files). The change adds wxAutoScrollHelper, yet another mixin which provides the API needed to configure and manage autoscroll settings along with support for changing target windows. While breaking out autoscroll, I've added some additional (IMHO required) support for configuring the range for which the window is autoscrolled based on mouse position, the rate it autoscrolls at, and the rate at which it accelerates (if it does). Default settings are configured to mimic the exact behavior as the old, currently built-in autoscroll functionality of wxScrolledWindow.
This change is shown with the addition of the autoscroll.cpp and autoscroll.h file additions. Please don't forget to copy these files to the appropriate location as they are not included in the main patch file.
File Locations:
autoscroll.cpp - src/generic/autoscroll.cpp
autoscroll.h - include/wx/autoscroll.h
You may notice that the new autoscroll implementation takes a slightly different approach. The old autoscroll uses wxEVT_LEAVE_WINDOW to start autoscroll, and stops on wxEVT_ENTER_WINDOW or when mouse capture is released. That design has some flaws unfortunately. If the mouse is moved around the window to the opposite side (without entering the window again), autoscroll continues to (incorrectly) scroll in the initial direction. The new implementation injects a wxEVT_MOTION event handler into the target window which is able to make corrections to the scroll direction, as well as make adjustments to the scroll speed.
This addition also required renaming the old wxAutoScrollTimer to wxDeprecatedAutoScrollTimer, which I felt was appropriate to indicate that the new wxAutoScrollHelper should be used instead.
I've only updated wx[H/V/HV]ScrolledWindow to use the new wxAutoScrollHelper classes. While it's very quick and easy to update other scrolled window classes to use the new wxAutoScrollHelper, I didn't have the time do extensive testing, so I've held off on it as it can be handled at another time after committing this patch to CVS.
The vscroll sample has also been updated to take advantage of the new autoscroll features as well, but it's note-worthy to point out that the original, unmodified vscroll sample does in fact build and run flawlessly with this new refactoring.
== What Work Remains Unfinished? ==
There has been some work done towards documentation of the old wxHVScrolledWindow patch that has been committed to CVS, but not listed in the class listing (left in there waiting for this patch to come along). That documentation is nowhere near complete, and will need some major updating before being listed. The work that remains in regards to updating the documentation has been held off so the approach for how to document this new refactored class hierarchy can be discussed on wx-dev before being written up. Watch this patch (and the wx-dev mailing list) for the future addition of a documentation patch.
----------------------------------------------------------------------
>Comment By: Vadim Zeitlin (vadz)
Date: 2007-04-01 16:38
Message:
Logged In: YES
user_id=71618
Originator: NO
I agree that as much as of the this patch as possible should be applied
a.s.a.p. and I think splitting the autoscrolling part (point 10) would be
enough to apply it right now so if you could please upload the updated
version I'd try to apply it a.s.a.p.
Otherwise let's discuss the remaining points on wx-dev, TIA!
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-03-26 02:37
Message:
Logged In: YES
user_id=1106696
Originator: YES
Just thought I'd follow this up really quick to note that I've tested my
latest changes with wxGTK, and couldn't find any problems. Seems to work
fine. I'll get wxMac tested shortly as well. Following that, I'll get the
docs written up while I wait on your reply to the issues I posted last. If
there are any remaining issues, they should be minor, and I'd like to see
this patch applied (when I get the new one up with docs and other already
discussed changes) so further work is more bearable where it won't involve
large changes with many files and the addition of the position.h file. We
can also start getting some testing done from others as well.
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-03-21 23:53
Message:
Logged In: YES
user_id=1106696
Originator: YES
0. Ah, this makes a lot more sense, thanks. I also find this funny since
it's actually possible to use wxAutoScrollHelper exactly like you describe
with the initial version posted here mostly because of the built-in support
for changing the target window (and the constructor which takes a target
window already in the patch). Only you would have to forward access to the
autoscroll settings from whatever class you're using it in. Do you have any
ideas on the best method of exposing those settings for windows using
wxAutoScrollHelper like this? How about writing a macro much like
WX_FORWARD_TO_SCROLL_HELPER, but for for the autoscroll settings? That was
most of my reason for using wxAutoScrollHelper as a base class. Would the
wxVarScrollWindow classes need to implement autoscroll this way, or just
the wxGTK implementation of wxScrolledWindow/wxScrollHelper, or both?
3. Ok, I will just toss it in a new position.h file then. My initial
thoughts were that gdicmn.h was just a little messy anyway, so this should
help in the direction of cleaning it up a little. It doesn't make a much
sense to me that you're required to include a file called "gdicmn.h" so you
can use wxSize with something like a new sizer for example. Anyway, that's
a discussion for another day.
4. I confirmed with Brad that this is the case, the comment is just
out-of-date from what his final implementation ended up being. I'll make
another pass over all comments in the patch to make sure there's not others
like this still sitting around while I add some comments to the classes
missing some.
7. (RE: empty event tables) Brad mentions that he had these in the
original patch initially expecting that he was going to use them, and
didn't end up actually doing so (I imagine the ProcessEvent override
handles everything these would have been used for). I'll remove these.
8. Well, wxScrolledWindow can be configured to not use physical scrolling
if the platform supports it, since to quote the official documentation for
wxScrolledWindow::EnableScrolling(): "Physical scrolling may not be
available on all platforms. Where it is available, it is enabled by
default." This is a feature we take advantage of in our application, so I
definitely don't want to see it disappear. Anyway, I also see no reason
why this function shouldn't at least be moved from wxScrolledWindow into
wxWindow (other than that it's yet one more function for the already
cluttered wxWindow class, which I know you're already slightly annoyed with
:)). Since you can still scroll a wxWindow without using wxScrolledWindow,
it should be an option configurable with wxWindow. Is this something you
have time to look at and write in the appropriate WXWIN_COMPATIBILITY_2_8
code, or would you like me to also take care of this? This could be
handled as separate patch.
10. I agree, it could take me a bit of time to come up with documentation
for autoscroll that's clear and to-the-point (highly technical
documentation was never one of my strong skills). I could also use some
time to look over the autoscroll patch you just referenced (thanks for that
btw, I wasn't previously aware of that patch). I'll split the autoscroll
specific code out of wxVarScrollWindow into a separate patch. This way, I
also have some extra time to remove the duplicate wxAutoScrollTimer code,
implement the new timer in both wxScrolledWindow/wxScrollHelper and
wxHtmlWindow (which already duplicates the existing autoscroll code even
though it's derived from wxScrolledWindow for some reason), and take care
of appropriate testing on all platforms of those classes, their
derivatives, and any other classes using wxScrollHelper. That comes down to
this list on initial inspection:
Common: wxRichTextCtrl
Generic: wxDataViewCtrl, wxGrid, wxTreeCtrl
Universal: wxTextCtrl, wxListBox, wxComboListBox
X11: wxTextCtrl
On a side note, wxTextCtrl on X11 derives from wxScrollHelper, but doesn't
declare WX_FORWARD_TO_SCROLL_HELPER(). It does forward the PrepareDC()
function though, should that be fixed to forward the rest?
I also noticed that (common) wxWindow contains a m_scrollHelper member
itself (with a getter and setter), which is set upon creation of
wxScrollHelper, but I can't find anything that actually uses it and it's
not a publically documented function. If I comment out these members and
the call in wxScrollHelper to set it, it doesn't break the build. Does
wxWindow really even need these functions? This could be a chance to pull
a tiny bit of weight off of wxWindow (not that it's a lot with a forward
declaration and pointer use). :)
Also, in the base wxWindow class, I'm not sure what to do about the
ScrollLines() function. Should this still be implemented for the variable
scrolled windows? I guess this is partly my fault since I wanted to remove
all references to "lines" and replace them with more clear terms.
ScrollLines() will of course continue to work with the
wxVarVScrollLegacyAdapter, but I think this should be left unimplemented in
all variable scroll windows (including the vertical one) so users won't be
tempted to use it as opposed to the preferred variable scroll window API.
If that's the case, I'm also thinking that a deprecation notice should be
written into the new wxVScrolledWindow class so those moving over to 2.9
(or later) without 2.8 compatibility turned on will be warned if their code
still uses ScrollLines() as it would only return false.
While I'm at it, here are all internal classes that should be looked over
with the wxVScrolledWindow part of this patch (not referring to autoscroll)
applied:
(this is for my own reference, but just so it's known what classes this
could affect...)
Common: wxSymbolListCtrl (part of wxRichTextCtrl), wxVListBox
Thanks for your advice and taking the time to review this massive patch.
P.S. If you'd like to move this discussion to the wx-dev list, that's
fine. I'm annoyed by this interface myself. I'd prefer to not to make the
discussion hard to follow for others looking back through here in the
future, but I'll leave that to you.
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-03-16 14:57
Message:
Logged In: YES
user_id=71618
Originator: NO
BTW, concerning autoscrolling: I wonder if you can find anything useful in
this old patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=762839&group_id=9863&atid=309863
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-03-16 14:56
Message:
Logged In: YES
user_id=71618
Originator: NO
0. My main reason for prefering a separate wxAutoScrollHelper is that I'd
like to reuse the same implementation for both wxVarScrolledWindow and the
normal wxScrolledWindow (and maybe in the future for native controls
too...) but it's going to be difficult to make them derive from the same
class. So I'd like to separate this class and be able to just say (in any
class handling the wxEVT_LINEUP/DOWN events)
m_autoScroll = new wxAutoScrollHelper(this);
and this would be enough to make the class auto-scrollbale (the class
would install itself as an event handler for passed in pointer and would
handle mouse events appropriately). Do you see what I mean?
1. Ok, thanks!
3. I think I still prefer a separate file but it's not a strong
preference...
4. I think comment should be just removed then, it seems out of date
6. Hmm, yes, please post to wx-dev if you want other opinions. But I
really had to think hard to understand what "orientation size" was. I don't
think such problem can happen with the notion of "size in scrolling
direction".
8. Oops, sorry, I forgot about this explanation, thanks for the reminder!
I do understand what it does now but I still wonder if we shouldn't just
always have it on because AFAICS wxScrolledWindow always behaves like this
and if we want to implement this sort of behaviour (scroll only pixels, not
children), we should do it in both places at once and even at
wxWindow::ScrollWindow() level.
10. Ok, I'm starting to see, thanks for the explanation. I think that at
least the sentence about this being necessary to implement autoscroll even
for maximized windows should be somewhere in the code (sorry if it's
already there and I missed it). As for being confusing, I guess it might
help if this was split in turn in a separate patch, I'd really like to
apply the V->HV part of the patch a.s.a.p. as I don't want it to bit rot
again...
Sorry to hear about the problem with "cvs add", unfortunately I don't know
what to do about it (cvs being not under our control).
Thanks again and good luck!
[marking as pending just so that I know I've answered this one and it
doesn't need immediate attention any more]
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-03-15 23:12
Message:
Logged In: YES
user_id=1106696
Originator: YES
VZ> 0. I'm not entirely sure I agree with the idea of making
VZ> wxAutoScrollHelper the base class here. IMHO it would be better if it
could
VZ> be associated with an existing class as I don't see how can we use it
with
VZ> native scrolled window implementations (currently GTK-only)
otherwise.
How would you recommend this should be handled. I don't really understand
exactly what the problem is. wxVarScrollWindow (I'm going to refer to the
wx[H/V/HV]ScrolledWindow classes collectively as wxVarScrollWindow from now
on, it's easier to type) should still process wxEVT_SCROLLWIN_LINE[UP/DOWN]
even if it's using a native scrolled window implementation, and
wxVarScrolledWindow should handle the job of scrolling right? Admittedly, I
haven't tested much of this work on wxGTK just yet, but plan to before a
final version of this patch is made.
VZ> 1. I think many wxVarScrollHelperBase methods, such as ScrollLines(),
VZ> should be protected instead of being public and should be only exposed
as
VZ> public by wxVarVScrollLegacyAdaptor as currently you can use both
VZ> ScrollLines() and ScrollColumns() with H-scrolled windows which is
IMO
VZ> confusing. I'd even rename ScrollLines() in the base class to some
VZ> DoScroll() to avoid confusion inside the implementation code (which
would
VZ> still have access to protected members) too.
I've come up with a new idea as to how to handle this. I'd still do
exactly what you recommend here (and I've already partially finished it),
but for everywhere we refer to "lines" in wxVarScrollHelper, we refer to
them as "units" (which doesn't imply or suggest an orientation) instead.
Then in wx[H/V]ScrolledWindow, we refer to them as "rows" and "columns"
like the patch already does, which also plays nicely with wxPosition. Then
in wxVarVScrollLegacyAdapter, we can support the old reference of "lines".
I think this would help clear up any confusion. "Lines" would eventually
disappear with wxVarVScrollLegacyAdapter both in docs and in code.
VZ> 3. I understand the lack of time needed to refactor wxGBPosition and
VZ> wxVSPosition but, still, why not just call the new class wxPosition?
VZ> wxGBPosition could be changed later, for now all that is needed is to
VZ> rename this class and put it also in a separate header.
I started work on this, but realized that creating a new file for ~100
lines of code that isn't likely to be expanded was more work than it's
worth, and decided it would be better placed in gdicmn.h (with wxSize and
family, especially since I added operator overloads for working with
wxSizes). While it's not really GDI related, wxSize isn't necessarily
specific to GDI either. Would you agree that this is appropriate?
VZ> 4. I didn't understand the comment "We can't easily multiply inherit
VZ> because of the shared base class so we'll use composition and write
an
VZ> adaptor interface" because the code seems to use MI and not
composition?
I'll defer this to Brad, I didn't write it, nor do I understand it.
VZ> 6. I realized that names Get[Non]OrientationTargetSize() are a bit
VZ> confusing. What about more explicit GetTargetSizeInScrollDir() and
VZ> GetTargetSizeInOtherDir()?
I personally think Get[Non]OrientationTargetSize() is more clear and
easier to read, that might be something to toss up to a vote.
VZ> 8. It's not totally clear to me what is EnablePhysicalScrolling() and
why
VZ> we don't want to have it always on?
Brad explained this in the old patch comments when you first asked this:
http://urlx.org/sourceforge.net/3c30d
I thought it was pretty clear, but if you're not clear on something, I'll
be happy to explain. It's exactly the same as
wxScrolledWindow::EnableScrolling(), only with a more clear name. We'd want
it on by default since first, it's what the default behavior in wxWidgets
is already set to, second, there's a small amount of extra work involved
with writing an application with it off, and third, it's more efficient
with it on (relying on internal OS capabilities to handle optimized
scrolling rather than always repainting the entire window).
VZ> 10. The notion of autoscroll range remains mysterious to me, in spite
of
VZ> the comment. I guess it would help to know what 0 and 1 correspond to.
And
VZ> having the docs for this stuff would be really great (helpgen can
generate
VZ> a skeleton).
I was worried this was going to be the one variable that was confusing. I
had a hard time thinking about how to explain what it does without using an
illustration. Most of the reason for being able to configure "range" is so
that you can still make autoscroll (and it's acceleration setting) useful
even when your scrolled window is maximized. Once the mouse reaches the
edge of the screen, it's impossible (without digging directly into mouse
hardware input) to tell how much the user still wants to push it off the
screen. Without that, it's impossible to calculate how fast the user wants
the window to autoscroll. So the range lets you configure autoscroll so
that it can be triggered even before the mouse leaves the window.
At the default range of 1, you're required to move the mouse outside the
border of the window to trigger autoscroll. At 0, autoscroll will pretty
much be triggered with the mouse anywhere inside the window as soon as the
window grabs mouse capture. At 0.5, autoscroll is only triggered if you
move the mouse out of the center 50% of the window (not actually 50%, but
50% of the distance to any of the borders from the center). An illustration
would definitely help, but I couldn't think of any other way to write this
functionality while keeping it flexible and not requiring extra effort for
the developer if the window is resizable.
Setting the range to 0 would not be desirable for 99% of applications, but
my application is one of the many that would benefit from setting the range
to a value around 0.75 instead of defaulting to 1, so this is a value I'd
like to keep configurable in wxWidgets. It's not a value that requires
configuration, so it won't hurt anyone that doesn't understand it.
VZ> 100. There are a couple of stray hard TABs and ^Ms in the patch as
well as
VZ> a few typos ("recieve", "widnow", "layed") which annoy me just
because
VZ> they're highlighted in red by Vim...
*sigh* ... I turned on visible whitespace in Visual C++ while I was
working on this, and tried to make sure I didn't miss anything. I'm also
not sure how ^Ms got in there since I was sure to do conversions before
submitting them, and I can't actually find any at the moment in the files
posted, but I'll make sure to sweep these up on the next patch update
(which should be soon after I get some more feedback on the items discussed
in this post).
VZ> Otherwise I don't have any real comments except that there is an
obvious
VZ> problem of duplicating autoscroll code between wxScrolledWindow and
this
VZ> patch. I hope it can be fixed, if not in this patch itself, then in
the
VZ> next one.
If I don't get around to this before this patch is ready to be committed,
I'll personally see to making sure it happens in plenty of time before the
next stable branch so it can be thoroughly tested.
VZ> BTW, if you resubmit the patch, you should be able to include new
files
VZ> directly into it by "cvs add"ing them first (this shouldn't require
write
VZ> access to the repository AFAIK) and then using "cvs diff -N". TIA!
I tried this not only with the standard cvs command line tools (on Mac and
Windows), but also with TortoiseCVS (which uses the command line tools
anyway), and both failed with the message: "cvs [server aborted]: "add"
requires write access to the repository". The only other CVS repositories
I've worked with I've had write access to, so I've never known if this is
supposed to work or not. I know it works with SVN though. So either it's
not possible in CVS, or the wxWidgets CVS server isn't configured
correctly.
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-03-10 18:18
Message:
Logged In: YES
user_id=71618
Originator: NO
Some comments/questions as I'm reading the patch:
0. I'm not entirely sure I agree with the idea of making
wxAutoScrollHelper the base class here. IMHO it would be better if it could
be associated with an existing class as I don't see how can we use it with
native scrolled window implementations (currently GTK-only) otherwise.
1. I think many wxVarScrollHelperBase methods, such as ScrollLines(),
should be protected instead of being public and should be only exposed as
public by wxVarVScrollLegacyAdaptor as currently you can use both
ScrollLines() and ScrollColumns() with H-scrolled windows which is IMO
confusing. I'd even rename ScrollLines() in the base class to some
DoScroll() to avoid confusion inside the implementation code (which would
still have access to protected members) too.
2. I think it would still be useful to have at least brief comments before
each class because when you're reading their declarations you don't see the
inheritance diagram near the top any more and so could have forgot what
each of them did. And wxVarVScrollLegacyAdaptor really needs to be
commented as it's probably non obvious for others what it does.
3. I understand the lack of time needed to refactor wxGBPosition and
wxVSPosition but, still, why not just call the new class wxPosition?
wxGBPosition could be changed later, for now all that is needed is to
rename this class and put it also in a separate header.
4. I didn't understand the comment "We can't easily multiply inherit
because of the shared base class so we'll use composition and write an
adaptor interface" because the code seems to use MI and not composition?
5. It would be nice to indicate why is wxDeprecatedAutoScrollTimer called
deprecated. Of course, it would be even nicer to get rid of it entirely
:-)
6. I realized that names Get[Non]OrientationTargetSize() are a bit
confusing. What about more explicit GetTargetSizeInScrollDir() and
GetTargetSizeInOtherDir()?
7. There are a couple of empty event tables for wx{H|V|HV}ScrolledWindow
-- why?
8. It's not totally clear to me what is EnablePhysicalScrolling() and why
we don't want to have it always on?
9. This is minor, but I think it would make sense to compile out
wxAutoScroll stuff entirely if !wxUSE_TIMER: such setting would presumably
be only set to save on executable space and it doesn't make much sense to
keep a relatively big autoscroll timer class which doesn't work anyhow
without timers in this case. It should also reduce number of #ifs.
10. The notion of autoscroll range remains mysterious to me, in spite of
the comment. I guess it would help to know what 0 and 1 correspond to. And
having the docs for this stuff would be really great (helpgen can generate
a skeleton).
11. The point (7) above needs to be undone if I'm not wrong about other
patch being incorrect
100. There are a couple of stray hard TABs and ^Ms in the patch as well as
a few typos ("recieve", "widnow", "layed") which annoy me just because
they're highlighted in red by Vim...
Otherwise I don't have any real comments except that there is an obvious
problem of duplicating autoscroll code between wxScrolledWindow and this
patch. I hope it can be fixed, if not in this patch itself, then in the
next one.
BTW, if you resubmit the patch, you should be able to include new files
directly into it by "cvs add"ing them first (this shouldn't require write
access to the repository AFAIK) and then using "cvs diff -N". TIA!
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-03-01 09:13
Message:
Logged In: YES
user_id=1106696
Originator: YES
File Added: autoscroll.cpp
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-02-28 21:09
Message:
Logged In: YES
user_id=1106696
Originator: YES
File Added: autoscroll.cpp
----------------------------------------------------------------------
Comment By: Bryan Petty (bpetty)
Date: 2007-02-28 21:08
Message:
Logged In: YES
user_id=1106696
Originator: YES
File Added: autoscroll.h
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1671181&group_id=9863
More information about the wx-dev
mailing list