Everyone else may already know this, but I never realized that a textfield’s SelChange event raises an EnableMenuItem event.
I was wondering why my app was so slow at typing in a textfield, it was because it was taking a long time building dynamic menus. Adding the SelChange event to the textfield and setting a “DontBuildMenus” flag to stop the menus from building worked wonders.
Just thought there might be newbies who’d appreciate being reminded of this!
When a user selects something in my app, right then is when I’d need to rebuild the menus so that they have the appropriate entries on them for whatever they selected, right? And then in EnableMenuItems I just enable/disable the already-built menu items, right?
That’s going to be “interesting”, given that what’s on the menus can change a lot, and scanning the menus for suitable objects may take almost as much time as building them does.
What about on Windows? Do we still rebuild menus in the EnableMenuItems event?
I looked up EnableMenuItems in the docs, but didn’t see any mention of all this, must be time for new glasses…
EnableMenuItems isn’t the only time you can change a menu
You can actually do that nearly ANY time
You should be enabling only - not generally rebuilding as this can induce slowness in places you dont want it or need it
Trust me I ran into this as well in the IDE
Now there MAY still be no other opportune time to do this
Keep it to a minimum
Try running your app with the profiler on and examine the results
[quote=252227:@Michel Bujardet]Indeed, under Windows, it is the same thing. Changing selection triggers EnableMenuItem, both in the control, but also in the window, and in App.
I would build the menu once and save it in a property to avoid losing precious time at every key punch.[/quote]
This i’d expect
My code would show you that EnableMenuItems happens ON EVERY KEYSTROKE which is where you CAN run into issues if you do a lot of rebuilding in enable menu items as you may do it on EVERY keystroke which would make typing slow