Selecting the Last Damage Pattern Does Nothing

[Neugeniko]

This Bug seems to have cropped up recently. Selecting the last incoming damage pattern does nothing. If a fit is saved with the last pattern then the resists will show 0% for all damage types in the pattern and show invalid ehp.

[blitzmann]

This is due to the ever-frustrating way wxpython menus work (or don't work, depends on how you look at them)

I've looked at this and cannot really see how to fix it. The last menu item doesn't get bound to it's correct action function, and nothing I've tried works. Damage profile menu is a bit unique as it's the only one that return a list of menu items to be displayed (other context plugins simply give one menu item with it's corresponding handler or a submenu which builds and handles it's own menu).

I will probably rework incoming damage patterns to be under their own submenu to work around this bug, as I can't be bothered to figure out again why the handling isn't working...

[blitzmann]

Little more info: the last item is trying to call the default activate() instead of our custom method. Again, it's due to not binding it correctly. Not sure why the other menu items are able to override the default action and have no problem.

[blitzmann]

k, so I actually had some time to sit down and trace exactly what is happening. I have a fix pending in a pull request, but will have to wait until I get back from holiday to check on Linux and OS X.

A bit of documentation, as I'm sure I'll be looking at this again at some point: What was happening was the context menu logic noted that these single menu items returned None as their submenu, so it went ahead and applied the default bind (which is not implemented in the damage pattern implementation, since we want to use our own custom handler).

The reason why the others worked is because on the last loop the others were being set via the linerootMenu.Bind(wx.EVT_MENU, self.handlePatternSwitch). However, on the last loop, the context menu handler would think it doesn't have a submenu, and then specifically bind the last menu item to the default one. Since it was the last one in the loop, it was bound correctly but then overwritten, and was not bound again like the others before it.

It was fixed simple by differentiating the return of sub menu. If None, the module is a simple single menu item. If False, it means that submenus are possible within the module but this item does not have one, and it will handle its own binding.

The context menu handler as a whole should be rewritten, but meh.