SelChange raises EnableMenuItem

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!

On OS X EnableMenuItems should only ENABLE menu items - not rebuild menus

Try this

  • start a new desktop project
  • add the EnableMenuitems event to the window & the App
  • in each simply put “System.debuglog CurrentMethodName”
  • put a text field on a window
  • open the Console application
  • run the sample project from the IDE
  • type into the text field

This isn’t a “bug” but a VERY fundamental change in how Cocoa handles menus vs how Carbon handled them
It’s right way down in the OS layer - not a Xojo bug

This was actually one of the things that the IDE was doing and what made some versions experience slowness
We’ve since rectified what we do in EnableMenuItems

So let me get this right -

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…:frowning:

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.

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

Yep! I’ve been profiling all morning, that’s what led me to look at EnableMenuItems.

This is a big help, thanks!

[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

Wonder where I’ve seen that effect ? :slight_smile: