|
|
On 4/15/24 12:38, 'Matthias Melcher' via fltk.general wrote:
I like to use a trick to avoid re-allocating menu item
arrays:
Huh, I never worried about re-allocating menu item arrays..
do you avoid it because it's slow, or is the idea to allow
pointers to not change?
When I build menus I always use add() to construct menus
dynamically,
as often I need to change the menus, such as in my app's main
menubar:
File -> Recent -> <dynamic list of
recently edited files>
Even for menus that I originally design not to change, I
figure inevitably
I'll need to add a feature that does involve dynamic changes,
so better
to always design for dynamic than to have to retrofit later.
So I always use find_item() to access menu pointers to avoid
problems
with old pointers going stale; that seems to be less brittle.
If there's any overhead for using find_item(), I've never
found it
to be a problem, even on slow machines with "large" menus.
.. I reserve an array large enough to hold
everything I may ever add, but I keep the spare items invisible
using the `FL_MENU_INVISIBLE`
flag (or call hide() on the menu item).
I always worry about trying to predict array sizes always
bites me
in the ass later, so I always try to do everything dynamically
with
add() and find_item().
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/0e04f5df-f0db-4826-970e-c45f4f72f0b4%40seriss.com.
[ Direct Link to Message ] | |
|
| |