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?
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.
/Andreas
> Andreas, would you please test the attached version?
>
> This is not the final version yet, but if it works in your
> context and is fast enough, this would be fine. It's a first
> proof of concept, but it shouldn't have the fix_focus problem,
> and it is very fast.
>
> As before, please replace Fl_Group::clear() with the attached
> full code.
>
> Albrecht
>
> ----- attached code -----
>
> void Fl_Group::clear() {
> int i,j;
> savedfocus_ = 0;
> resizable_ = this;
> init_sizes();
> // okay, now it is safe to destroy the children:
> // revert them first
> if (children_ > 1) {
> Fl_Widget *temp;
> Fl_Widget **a = (Fl_Widget**)array();
> for (i=0,j=children_-1; i<children_/2; i++,j--) {
> temp = a[i];
> a[i] = a[j];
> a[j] = temp;
> }
> }
> while (children_) { // delete all children
> Fl_Widget* o = child(children_-1); // last child widget
> if (o->parent()==this) { // should always be true
> if (children_>1) { // optimized removal
> o->parent_ = 0; // reset child's parent
> children_--; // update counter
> } else { // slow removal
> remove(o);
> }
> delete o; // delete the child
> } else { // should never happen
> remove(o); // remove it anyway
> }
> }
> }
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
