QPoint does not have a constructor that takes double, double
as arguments, but it could be that implicit casting by your
compiler has it thinking that your move( double, double ) method
overrides the move( const QPoint & method ) by implicit construction
of a QPoint from the two doubles. This doesn't seem likely to me,
since it would involve two casts (from double to int, then from
ints to QPoint), and this violates the C++ implicit conversion rules.
I don't know the details of your compilers.
However, the picker's move method is part of the state machine,
and it may not be the best thing to reimplement. Perhaps you should
look at reimplementing widgetMouseMoveEvent() instead if you need
something other than the standard mouse move behaviour.
I did something similar recently. In our already-existing MFC
applications, we have mouse behaviour as follows:
- left click - drag - release: zoom in
- left click - release: zoom out
- right click - drag - release: select range
- right click - release: select point
Because our users are familiar with this behaviour, we do not
want to change it. Unfortunately, the "standard" in qwt uses
left button to zoom in and right button to zoom out. Using a
single button to do both means writing a customized event handler.
I reimplemented widgetMouseReleaseEvent() to check to see if the
selection() polygon is small (less than 5 pixels). If so, I assume
it is a single click and zoom out, otherwise I use the standard
release event handler to zoom in.
I have also complained a little about some of the difficulties
in understanding Qwt. However, I am finding out that the more
problems like this that I have to solve on my own, the more I
understand how it all works.
I don't know how Uwe feels about others contributing to this
project, but I am thinking that some short tutorials might be helpful
in addition to the example projects. This would mean creating
documentation outside of doxygen and make the job more difficult
as qwt continues to evolve. i would be happy to contribute
some things as I have time.
David Stranz, Ph.D. david_stranz@...
Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA 95356
Tel: (209) 545-8508
> -----Original Message-----
> From: Matthias Reich [mailto:matthias.reich@...]
> Sent: Wednesday, January 28, 2009 5:01 AM
> To: List for both Qwt users and developers
> Subject: qwt-plot with included zoom engine
> Dear all,
> I'm building a qwt_zooming_plot that incorporates a
> qwt_plot_zoomer with
> some reasonable defaults, which saves me time, when I create overview
> plots with lots of different plots stacked in one widget,
> where all the
> individual plots are supposed to have zooming capability.
> I'm building this on (i386) linux & (SPARC) solaris at the same time.
> Currently I've only succeeded to link successfully against a
> CC compiled
> QT, so I'm using CC to build the qwt programs.
> CC gives some other warnings than gcc and this led me to this
> qwt_plot_zoomer reimplements the method move(double,double),
> but there
> is no prototype in qwt_picker (the base class), however,
> qwt_picker (and
> qwt_plot_picker) DO HAVE a move(QPoint&) method.
> Now CC complains that qwt_plot_zoomer's move method hides
> move method.
> Is this "hiding" of the picker method intentional ?
> Did you mean to overload this method ? Should there be a template in
> qwt_picker to allow a move(double,double) method ?
> On another page, since I'm now digging into qwt_zoomer quite
> a bit, it
> would be possible for me to report bugs, if I find any.
> However, since
> some of the methods have only very shallow documentation, I sometimes
> fail to see the rationale behind certain things. If I don't
> know what a
> method or parameter is supposed to do, I can't figure out, whether
> there's a bug or not.
> I do look at the examples, but they just do what they're
> supposed to do.
> Whenever I want to do something else, I usually default to trial and
> error with things like setZoomBase() and zoom() before and after init
> and so on...
> As soon as you start to add functionality (like sending signals to
> neighboring plots for axis synchronizing), you'd better had the
> fundamentals working as expected, which I still struggle with.
> Sorry for the ranting undertone, but while I find qwt
> incredibly helpful
> (and I'll keep using it), the lack of explanations on the
> rationale of
> some things just hurts sometimes.
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> qwt-interest mailing list