Problems detecting key combinations in WinForms app under Mono on Mac

Question

I'm trying to get a .net 2 Windows.Forms application running on the Mac using Mono. The application has key combination short cuts for all functions, which have pre-defined defaults and can be reconfigured by the user. The Form KeyDown event handler looks up the action to be performed.

My problem is relating the Modifiers and KeyCode to the actual keys pressed. I don't mind if some mapping needs to be added for the Mac, but I need at least 3 modifier keys. However of the 4 modifiers on the Mac, few seem to produce obvious results. I get: Shift - works as expected Ctrl - reports a different KeyCode, but with correct modifier (eg Ctrl+N has Modifiers = Control and KeyCode 14 = "RButton, Clear").
Alt - reports some other key, unmodified (eg Alt+R gives KeyCode = 168 = "BrowserRefresh") Cmd - reports as Alt with expected KeyCode (eg Cmd+N appears as Alt-N)

I presume that the Cmd key would normally be used where Ctrl is used on Windows. Can anyone advise which of the three Mac keys I should be trying to use? And most importantly how to parse the KeyEventArgs to consistently report a base key plus three optional modifiers?

Mono is the latest version (as of a week or two ago), and it's a MacBook Air, OS X 10.8.1 if that makes any difference.

Answer 1

I get the same issues. Try using IRC and asking at irc.gnome.org on rooms Mono and MonoMac. Very helpful folks.

Apparently with MonoMac, which lets you build a native UI in Interface Builder and helps stub out your backend C# code to talk to it (that is, MonoMac is Mono talking to native Mac, not Mono running on a Mac; the second is just plain Mono), Windows.Forms support has dropped to the wayside -- I was told that Windows.Forms is essentially "dead" on the Mac, and the quiet bugzilla page seems to support that. It really is quite buggy. I ran into SelectionBackColor not working in RichTextBox right off the bat, then menu accelerators not working reliably. Windows.Forms on Mac is alpha to beta quality, I think.

That said, for what's essentially a labor of love, a surprising amount of Windows.Forms works well, but I wouldn't use it for a polished app. Good luck.

EDIT: I realize the OP wasn't specifically talking about menuitems, but here's a bug report about accelerators and menu items not working so well, just to speak to related bugginess.

[Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut

Windows.Forms on Mono is so close to working, it's tempting to think it's going to support what you need to get done, but, imo, to consider it solid enough for use beyond making quick utilities would be a mistake.

Answer 2

In case it's useful to anyone, this is where I ended up: I eventually managed to hack my way around this particular 'feature' by creating a new KeyData value to replace the one provided by the event (this code running only if it's a Mac). I swapped round some of the modifiers to make it more consistent with windows (ie if Cmd was pressed, and reported as Alt by Mono I changed that to Ctrl). I also filtered out ctrl+A to ctrl+Z which return KeyCodes 0 to 25 (not 65 to 90) and replaced these with their normal values. Fortunately my code only wanted the KeyData. It wouldn't be possible to create a new KeyEventArgs using the updated data, since Mono checks the current keyboard state and sets modifier flags for any pressed modifier keys, in addition to any modifiers passed to the KeyEventArgs constructor.

BUT - as ruffin commented Mono on the Mac is very flaky. We've parked this work for the moment as it's taking quite a bit of time to work around all the problems. So far we've managed to find a solution for each item we've looked at, and may well come back to this - but at best it will be a nasty hack to get this S/W running on the Mac.