#188 QwtPicker setTrackerMode problem

None
wont-fix
nobody
None
5
2013-11-01
2013-05-22
No

Suppose you have the following code:

QwtPlot *p = new QwtPlot(this);
QwtPlotPicker *pp1 = new QwtPlotPicker(p->canvas());
pp1->setTrackerMode(QwtPicker::AlwaysOn);
QwtPlotPicker *pp2 = new QwtPlotPicker(p->canvas());
pp2->setTrackerMode(QwtPicker::ActiveOnly);
pp2->setEnabled(false);

What happens is that even though the pp1 picker is active, the last call to setMouseTracking() for the QwtPlot widget was made with a false parameter, so the pp1 picker will behave as if it was set to QwtPicker::ActiveOnly. In fact, it is a bit worse, as after the picker is used, the tracker text is left on the plot in the place the mouse select key was released.

In my oppinion, the right thing to do is:

  1. Create the picker in a disabled state;
  2. Initialize the desired tracker mode;
  3. Switch mouse tracking for the widget upon the call to setEnabled() for the picker.

That way, there would be no strange "initialization order side effects" and the picker setting that would be active would correspond to the enabled picker.

This behaviour is present in version 6.0.1, but last time I checked, the svn code will behave the same.

Regards,
Marcelo.

Discussion

  • Uwe Rathmann

    Uwe Rathmann - 2013-09-01

    There are issues with restoring the mouseTracking() property of the canvas, but the example above shows none of them.

    As the mouseTracking property of the canvas is true when pp2 is created ( because of pp1 ) pp2 will never set mouseTracking() to false for the canvas.

    See the implementation of QwtPicker::setMouseTracking().

     
  • Marcelo Roberto Jimenez

    The first paragraph after the example clearly illustrates what I consider an issue. It took me some debugging into Qwt to figure out the problem and report it here.

    Look at the issue from the "programmer using the API"'s point of view. The QwtPlotPicker pp1 has been programmed to behave as "AlwaysOn", and in the end it behaves as "ActiveOnly". This is unexpected and inconsistent.

    If you believe this is not the case, feel free to close the issue. I have worked around the problem by initializing pp1 and pp2 in the reverse order.

    Regards,
    Marcelo.

     
  • Uwe Rathmann

    Uwe Rathmann - 2013-09-03

    With the code snippet above pp1 is always on and pp2 is disabled - exactly how it is supposed to be ( I did a quick check with adding your code to one of the Qwt examples ). Maybe you can append a small compilable demo application showing the issue ?

    The issue I'm aware of is, that when you destroy the picker in reverse order the mouse tracking property is not restored properly.

     
  • Uwe Rathmann

    Uwe Rathmann - 2013-11-01
    • status: open --> wont-fix
    • Group: -->
     


Anonymous

Cancel  Add attachments