Thanks, Albrecht. I think I'll wait for your solutions for both preventing 
crashes and avoiding the fix_focus problems, before deciding if I should delete 
my Fl_Scroll or append the Fl_button patch.

I have all respect for that you have other things to attend to, but I'm looking 
forward to your next update.

/Andreas


> This is a multi-part message in MIME format.
> --------------040207080800040805010600
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Andreas Ekstrand wrote:
> > Albrecht,
> >
> > This solution was sure fast enough (61ms compared to previous 1500ms), at 
> > least normally. In some cases though, the fix_focus still causes problems, 
> > even slower than before, actually over 60 seconds for one clear in debug 
> > mode.
> >
> > I middle-click on a button in my Fl_Scroll and the clear method is called 
> > before recreation of the scroll contents. Maybe because the middle-click it 
> > seems like the fix_focus problems appears again, even more serious. Any 
> > idea why?
>
> Not really, but I can reproduce this now with a slightly modified test
> program. There are two different, but related problems with this:
>
> Problem #1:
> If you click a button inside the Fl_Scroll and call any version
> of clear(), then this deletes the button in its own callback. This
> is problematic, and the usual way to avoid this (since FLTK 1.1.5)
> is to use Fl::delete_widget() to do such things. Unfortunately your
> use case doesn't qualify for this unless you accept to also delete
> the Fl_Scroll itself and recreate it as well. Then you could try
> to remove() the Fl_Scroll from its group (or window), call
> Fl::delete_widget(scroll), and finally create and add a new
> Fl_Scroll widget with its new contents.
>
> That said, my intention is to make clear() work in this scenario
> as well, i.e. to allow a widget to delete itself in its callback,
> but this needs more testing.
>
> I have a patch that removes some bad behavior (crashes in some
> cases), but this one alone doesn't solve your problem.
>
> To get an impression of the problems with this, you can read
> STR #1306: <http://www.fltk.org/str.php?L1306> . It's not yet
> complete, but the patch mentioned above is one of mayn that need
> to be tested and committed yet.
>
> Anyway, I append Fl_Button.patch. This might help you prevent
> a crash, but doesn't solve ...
>
> Problem #2:
>
> The time consuming problem is now probably the fix_focus stuff,
> but only if you click a button inside the Fl_Scroll. As I wrote
> before, this is probably not very useful, because this sends events
> to widgets that are about to be deleted anyway but do still exist
> as children in the group. This is at least in the order of n**2
> where n = children(), and that make it scale so dramatically with
> your number of children.
>
> > I can issue the same clear and recreation sequence with another button 
> > without clicking in the Fl_Scroll. This doesn't cause the same problem, so 
> > I guess the event sent to the button, causing the clear method to be 
> > called, is the problem here somehow.
>
> Yes, I can confirm this, and I'll do more investigation, when
> I have the time, but probably not before the weekend. :-(
>
> Albrecht
>
> --------------040207080800040805010600
> Content-Type: text/plain;
>  name="Fl_Button.patch"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="Fl_Button.patch"
>
> Index: src/Fl_Button.cxx
> ===================================================================
> --- src/Fl_Button.cxx (revision 7052)
> +++ src/Fl_Button.cxx (working copy)
> @@ -117,7 +117,11 @@
>      else {
>        value(oldval);
>        set_changed();
> -      if (when() & FL_WHEN_CHANGED) do_callback();
> +      if (when() & FL_WHEN_CHANGED) {
> +     Fl_Widget_Tracker wp(this);
> +        do_callback();
> +        if (wp.deleted()) return 1;
> +      }
>      }
>      if (when() & FL_WHEN_RELEASE) do_callback();
>      return 1;
> @@ -156,6 +160,7 @@
>      if (Fl::focus() == this && Fl::event_key() == ' ' &&
>          !(Fl::event_state() & (FL_SHIFT | FL_CTRL | FL_ALT | FL_META))) {
>        set_changed();
> +      Fl_Widget_Tracker wp(this);
>        if (type() == FL_RADIO_BUTTON && !value_) {
>       setonly();
>       if (when() & FL_WHEN_CHANGED) do_callback();
> @@ -163,6 +168,7 @@
>       value(!value());
>       if (when() & FL_WHEN_CHANGED) do_callback();
>        }
> +      if (wp.deleted()) return 1;
>        if (when() & FL_WHEN_RELEASE) do_callback();
>        return 1;
>      }
>
> --------------040207080800040805010600--

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to