Minor planner bugs

K. "pestophagous" Heller pestophagous at gmail.com
Thu Oct 22 22:38:16 PDT 2015


On Wed, Oct 21, 2015 at 10:54 AM, K. "pestophagous" Heller
<pestophagous at gmail.com> wrote:
> On Wed, Oct 21, 2015 at 12:59 AM, Robert Helling <helling at atdotde.de> wrote:

>> I think this is a valid analysis. We had problems at other places when a
>> replot was triggered while in the middle of some operation. For this there
>> is
>>
>> MainWindow::instance()->graphics()->setReplot(false);
>>
>
> ahhh! good to know. That sounds like it would help me.  I will try it
> and report back. Thanks!
>
> /K

Under the current implementation of setReplot(false) and the boolean
ProfileWidget2::replotEnabled, inserting a matched pair of
setReplot(false)/setReplot(true) will not help.  The reason: only
ProfileWidget2::replot obeys that flag, and in my bug-repro scenario,
the calls go to ProfileWidget2::plotDive and bypass replot.

Clearly, we *could* make plotDive honor the replotEnabled bool, but I
ended up favoring a different solution.  I posted it under subject
"[PATCH] Avoid plotting when ProfileWidget2::plotDive is called
speciously".  The approach is something I hope will be more resilient,
in that it doesn't require anyone in the future to remember (or learn)
to use setReplot(false)/setReplot(true).

Note: this patch fixes "my" bug-repro scenario, but I don't
necessarily expect it to fix Martin's original bug report.

Of course, I welcome Martin to check if it does.  Maybe tomorrow I
will try to dig deeper into how I could possibly reproduce anything
similar to Martin's way of encountering "Too many gas mixes".

hasta maƱana
/K


More information about the subsurface mailing list