On Wed, Oct 21, 2015 at 10:54 AM, K. "pestophagous" Heller <pestophag...@gmail.com> wrote: > On Wed, Oct 21, 2015 at 12:59 AM, Robert Helling <hell...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
