Same reason as on a Mac
It MIGHT open
No but it fires on every keystroke when you edit text in text area 
Yeehaw !
Enable menu items SHOULD be “enable = true” etc and not very much wiping menus out & rebuilding them for exactly this reason
See the very long threads about code editor speed which relates to exactly this problem
Hmmm seems those threads may not be accessible to you as ones in the beta channel & the other in Xojo pro
The gist is to do as little rebuilding menus as you can possibly can in enable menu items
Add items to submenus in other events / methods and then just enable & disable in enable menu items
For instance the IDE has a Scripts menu
One portion is scripts next to the IDE itself
That chunk is built once when the IDE starts and never rebuilt
The other portion is scripts for the project
And that can be rebuilt when different document windows are activated
Or when you add one via “new script”
Then enable menu items doesn’t have to touch it in enable menu items
And thats good because that could mean reading disk & if the project is on a remotely mounted volume that could be slow as heck
And that would make enable menu items very slow
[quote=229531:@Norman Palardy]No but it fires on every keystroke when you edit text in text area 
Yeehaw ![/quote]
Oh my stars.
[quote=229531:@Norman Palardy]Enable menu items SHOULD be “enable = true” etc and not very much wiping menus out & rebuilding them for exactly this reason
See the very long threads about code editor speed which relates to exactly this problem[/quote]
…
[quote=229532:@Norman Palardy]The gist is to do as little rebuilding menus as you can possibly can in enable menu items
Add items to submenus in other events / methods and then just enable & disable in enable menu items[/quote]
This seems reasonable. Similar to keeping at App.Open event as short as possible. Your example also helps. I’ll have to refactor a bit since this is my history menu. I’ve done it the same way in many apps now, but I see it causes potential catastrophe on Windows.
[quote=229518:@Tim Hare]As a workaround, try
while myMenu.Count> 0
meMenu.Remove(0)
wend[/quote]
BTW, this improvement over the code I was using changed the nature of the crash from OutOfBoundsException to a hard crash (Program Not Responding, shut down message from Windows). The reason seemed to be that this event was getting called a billion times a second, so I did a workaround:
#if TargetWin32 then
dim Now as double = microseconds
dim ElapsedTime as double = LastCallToEnableMenuItems - Now
LastCallToEnableMenuItems = Microseconds
if ElapsedTime < 1000000 then return
#endifsetting the property LastCallToEnableMenuItems as Double in the window
This seemed to suppress the crash for a wile, and then it happened again.
So, we’ll see about removing all the code that builds menus from this event, and I’ll report back.
[quote=229534:@Aaron Hunt]Oh my stars.
[/quote]
This is a side effect of how cocoa handles menus
You can try it out on OS X really easily
Put a text field on a layout and implement the windows enable menu items event (just put a break)
Run & type letters
EVERY key press fires enable menu items
But thats also why you can put DEL as a keyboard shortcut & have the delete key activate a menu item
And you can do that with ANY single keystroke - there are just very few that it makes any sense to do this with
[quote=229534:@Aaron Hunt]
This seems reasonable. Similar to keeping at App.Open event as short as possible. Your example also helps. I’ll have to refactor a bit since this is my history menu. I’ve done it the same way in many apps now, but I see it causes potential catastrophe on Windows.[/quote]
History is quite possibly one you can add to / remove from when those history entries are added & removed instead of when the enable menu item event is raised
Those are exactly the sorts of things that are easy to put in enable menu items but may have negative side effects
Putting the add / remove logic where you KNOW you are adding one or removing one makes sense
[quote=229537:@Norman Palardy]
Put a text field on a layout and implement the windows enable menu items event (just put a break)
Run & type letters
EVERY key press fires enable menu items
But thats also why you can put DEL as a keyboard shortcut & have the delete key activate a menu item
And you can do that with ANY single keystroke - there are just very few that it makes any sense to do this with[/quote]
Mind-blowing.
Yes, it does. And, not that hard to change it from building in the event.
Unfortunately, having removed the menu-building code from the EnableMenuItems event, this has not stopped the crashing.
The crash no longer takes place in the event. It’s now just a hard APPCRASH.
It happens when pressing the Control key, not every time. After having used, or during use of, the MouseWheel.
I’m tracing this to my implementation of a MouseWheel “watcher”, which is obviously working differently on Windows than it does on Mac:
https://forum.xojo.com/27616-undo-strategy-for-mousewheel-actions
It appears the MouseWheel events on Windows fire differently and interact differently with computed properties than they do on a Mac…
I’ve found the issue. I’ll write about it on the other thread (linked above) since it’s more relevant there.
Oh you have no idea how much joy that change has caused me