bizarre OutOfBoundsException on Menuitem.Remove only on WIndows

In the EnableMenuItems event, this code

dim j, k as integer
k = myMenu.count - 1
for j = k downto 0
  myMenu.remove(j)
next

Works fine on Mac, throws an OutOfBoundsException on Windows, when j= 0. Debugger shows k is a positive value.

?

Makes no sense.

And if I use Exception, or Try … Catch, along with a #Pragma BreakOnExceptions False / True block to ignore the exception, the debug app results in a hard crash.

I have had situations in which I can only use a menuItem once when using .PopUp()

I work around this by always cloning all menus before calling .PopUp() on them.

Could you use a similar technique? Operate on a copy of the menus, not the originals?

That’s a different issue. I use .clone for on-the-fly menu items under Cocoa to avoid the problem you mention.

This is a menu item that already exists in a MenuBar, and is populated in the EnableMenuItems event. Before showing it to the user, I delete all existing items and add items from an array of strings that changes as the user works (it’s a history list).

[quote=229113:@Aaron Hunt]In the EnableMenuItems event, this code

dim j, k as integer
k = myMenu.count - 1
for j = k downto 0
myMenu.remove(j)
next
Works fine on Mac, throws an OutOfBoundsException on Windows, when j= 0. Debugger shows k is a positive value.[/quote]

Just tried that code in 2015R3.1. No error. The menu is emptied, that is all.

Is that all the code you have in EnableMenuItems ?

There is no error in the code, and no reason it should crash. Like I said, it makes no sense.

There is code after deleting the menu items which populates the menu, but the debugger never even gets there on Windows. Everything works fine on Mac.

[quote=229497:@Aaron Hunt]There is no error in the code, and no reason it should crash. Like I said, it makes no sense.

There is code after deleting the menu items which populates the menu, but the debugger never even gets there on Windows. Everything works fine on Mac.[/quote]

Maybe you are to check with a test app with only the code you posted, as I did. No error.

Well, right. There is no error in my code, and no reason for this exception happening. That’s the point.

I am trying to tell you that a test app containing ONLY that code does not crash. Which implies that the issue must be elsewhere.

Right. So what it is then?

The EnableMenuItems event is in fact firing at random times. And then this crash happens.

What in the world could cause that?

The only way I can cause the outOfBound is by letting j start at menuCount.

When I comment out the code above, then it doesn’t crash… which only seems to indicate that the problem IS in that code.

Then it has to be in the value of j.

Turn on Break on Exception and see which value it has when the exception occurs.

[quote=229510:@Michel Bujardet]Then it has to be in the value of j.

Turn on Break on Exception and see which value it has when the exception occurs.[/quote]

I did, of course, first thing. See above. It crashes on j = 0, k is positive.

Impossible to replicate your issue here. I give up. Get an exorcist …

What is myMenu.Count? Probably zero as well. This sounds like potential reentrancy. What does the stack look like when it crashes? Do you have any calls to DoEvents in your app?

As a workaround, try

while myMenu.Count> 0
   meMenu.Remove(0)
wend

I’m also thinking it’s reentrancy…

No, there are no App.DoEvents calls in this app.

Thank you, your while … wend code is a cleaner approach.

Something related, I just found (by putting only “beep” in the EnableMenuItems event) that the EnableMenuItems event of a window fires on Windows 7 when these keys are pressed:

  • Shift
  • Control
  • Alt (fires twice: on key down and key up)

That is really troubling! Can I stop that from happening?

Why would you want to stop them ?
Shift+Key is a possibly valid key combination as is Ctrl+Key for triggering a menu

I understand why pressing these keys would fire if the menu was open, since on Windows it means the menu text can change, but why do they fire when no menu is open? Seems like the event should fire when the assigned key + modifier is pressed, not when the modifier key is pressed by itself. I guess this has to do with how keys events are tracked.

Is there a note somewhere about this difference between Mac and Windows? Seems pretty important to know. At least, in working with key combinations it has caused me a lot of headaches in the last few hours that could have been avoided.

To make the app behave the same way on Windows as it does on Mac. The EnableMenuItems event doesn’t fire when modifier keys are pressed on Mac.