[RFC] String corruption when clearing MenuButton when popped-up

[Greg Ercolano]

[This was posted on fltk.general, carrying it over here on fltk.coredev for possible discussion]

On 11/5/22 01:11, Mo_Al_ wrote:

Hello

Is there a way to detect whether Fl_Menu_Button is popped-up prior to calling clear on it?

On 11/5/22 01:48, Manolo wrote:

While the menu is pulled down, Fl::grab() returns the menu window and it returns NULL when the menu window is closed.

Thus, you can modify your timeout_cb function as follows

void timeout_cb(void *) {
  puts("running timeout");
  if (!Fl::grab()) {
    m->clear();
    m->add("Jan|Feb|Mar");
  }
    Fl::repeat_timeout(1.0, timeout_cb, 0);
}

If there are other grabbing windows around in your app, you would also have to make sure Fl::grab() returns another window.

    I can see where applications showing realtime status of asynchronous events could run into this easily.

  * Should FLTK provide is_posted() or is_popup() or some such method to Fl_Menu_ and friends?

  * Add warnings in docs for all the Fl_Menu_ 'clear()' methods/suggest how to avoid?

  * Perhaps clear() methods should automatically schedule/defer the work until the menu finishes posting?

[melcher....@googlemail.com]

+1 : I don't find it extremely useful, but it is a protective measure and takes only a few lines of code.

[Manolo]

Le dimanche 6 novembre 2022 à 15:50:39 UTC+1, Matthias a écrit :

+1 : I don't find it extremely useful, but it is a protective measure and takes only a few lines of code.

+1 on my side too. Another suggestion for the name: is_running()

[Albrecht Schlosser]

On 11/6/22 15:50 'melcher....@googlemail.com' via fltk.coredev wrote:
> +1 : I don't find it extremely useful, but it is a protective measure
> and takes only a few lines of code.

+1 from me too if you (Matthias) can do it. I don't feel very
comfortable with all this menu stuff, it's hard to see what's going on.

In addition to the general issue: the docs warn at several places that
menus must not be cleared in a menu callback. This should probably be
extended to say "while the menu is open(ed)" because this could also be
done (ehm, tried!) from timer callbacks while the menu is open (popped up).

Whether we can prevent bad things from happening (don't execute clear()
etc. while the menu is open, I don't know. And I doubt that we can, but
maybe ...

[imacarthur]

On Saturday, 5 November 2022 at 09:36:23 UTC er...@seriss.com wrote:

    I can see where applications showing realtime status of asynchronous events could run into this easily.

Though in (I do not know how long) I don't think I have ever actually hit this, so it might not be that common a use case?

  * Should FLTK provide is_posted() or is_popup() or some such method to Fl_Menu_ and friends?

Or some variation on visible() perhaps?

It seems to me that this is "similar" to what the visible() method does for a regular widget, so maybe the same method name would  be appropriate here?

  * Add warnings in docs for all the Fl_Menu_ 'clear()' methods/suggest how to avoid?

  * Perhaps clear() methods should automatically schedule/defer the work until the menu finishes posting?

Though that might get a bit more involved?

Anyway, the basic idea sounds sensible to me: +1

 

[Greg Ercolano]

On 11/6/22 08:51, imacarthur wrote:

On Saturday, 5 November 2022 at 09:36:23 UTC er...@seriss.com wrote:

    I can see where applications showing realtime status of asynchronous events could run into this easily.

Though in (I do not know how long) I don't think I have ever actually hit this, so it might not be that common a use case?

    I can think of an example in my own case; an application that shows the status
    of a USB device being plugged in or not, updating whenever the device is plugged
    in or removed.

    I show the status in a label, which should be safe.

    But I can see where if I had used a pulldown menu that changed contents when the
    USB status changed, that situation could crash the app. And that might go undetected
    in Q/C. I should probably review that application to be sure there isn't such a situation..

  * Add warnings in docs for all the Fl_Menu_ 'clear()' methods/suggest how to avoid?
  * Perhaps clear() methods should automatically schedule/defer the work until the menu finishes posting?

Though that might get a bit more involved?

    Agreed it might be involved, and if we can't implement it cleanly,
    then we really must warn about the situation in the docs, then.
    I think we already have a warning about the app keeping possibly
    stale pointers to items.

    As tough as it is for FLTK to implement, I think it'd be even tougher for the
    application software to do it.