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.
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.
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.
Related
I'm using tmux window manager with OS X's terminal. I'd like to be able to use the key bindings to switch between tmux panes or split them instead of having to type out 'tmux select-pane' or 'tmux split-window' every single time. However, pressing CTRL and b together, which according to the man page is the default key binding, has no effect.
For example, the man page says I should be able to type CTRL and b (or, as it puts it, C-b) along with " to split the window. Pressing these keys together does nothing. None of the key bindings produce any effect in tmux.
I tried googling the issue and got back lots of results telling me to edit my ~/.tmux.conf file, but I don't have this file at all. It doesn't exist and was not created when I installed tmux using MacPorts, thus I cannot edit it to change the key bindings.
I can't find anyone who has had a similar problem, that of the key bindings not producing any effect at all. What am I doing wrong? Does the Macbook Pro keyboard simply not support key bindings? I'd appreciate it if someone could shed light on what my problem is.
Do simple commands work? Like C-b , to rename the window? If not maybe try using iTerm2?
I wrote a large complex C program around 20(!) years go. As far as I can recall it worked fine at the time in all respects - it was probably running on windows 95.
Now I need to use it again. Unfortunately the radio buttons in it do not appear to work properly any more (the ordinary push buttons are all behaving correctly). As I click on the radio buttons, I get some feedback that windows is acknowledging my click in as much as I see a dotted line appear around the button's text and the circle of the button goes grey for as long as my finger is on the button, but when I take my finger off I see that the selected button has not changed.
My suspicion is that I was perhaps getting away with some bad practice at the time which worked with windows 95 but no longer works on newer versions of windows, but I'm struggling work out what I did wrong. Any ideas?
EDIT: Its difficult to extract the relevant code because the message handling in this program was a tangled nightmare. Many buttons were created programatically at runtime and there were different message loops working when the program was in different modes of operation. The program was a customisable environment for running certain types of experiment. It even had its own built-in interpreted language! So I'm not expecting an answer like "you should have a comma instead of a semicolon at line 47", but perhaps something more like "I observed similar symptoms once in my program and it turned out to be ..... " .. or perhaps "the fact that the dotted rectangle is appearing means that process AAA has happened, but maybe step BBB has gone wrong".
EDIT: I've managed to extract some key code which my contain an error...
char *process_messages_one_at_a_time()
{
MSG msg;
int temp;
temp = PeekMessage(&msg,winh,0,0,PM_NOREMOVE);
if (temp)
{
GetMessage (&msg, NULL, 0, 0);
if (msg.message == WM_LBUTTONUP)
{
mouse_just_released_somewhere = TRUE;
}
TranslateMessage (&msg);
DispatchMessage (&msg);
}
if (button_command_waiting)
{
button_command_waiting = FALSE;
return (button_command_string);
}
else
{
return (NULL);
}
}
There are two simple things to check when using radio buttons. First is to make sure that each has the BS_AUTORADIOBUTTON property set. The second is to make sure that the first button in the tab order and the next control after the set of buttons (typically a group box) have the WS_GROUP property set, while the other buttons have it clear.
A few suggestions:
I'd try to use spy++ to monitor the messages in that dialog box, particularly to and from the radiobutton controls. I wonder if you'll see a BM_SETCHECK that your program is sending (ie, somewhere you're unchecking the button programatically).
Any chance your code ever checks the Windows version number? I've been burned a few times with an == where I should have used a >= to ensure version checking compatibility.
Do you sub-class any controls? I don't remember, but it seems to me there were a few ways sub-classing could go wrong (and the effects weren't immediately noticeable until newer versions of Windows rolled in).
Owner-drawing the control? It's really easy to for the owner-draw to not work with newer Windows GUI styles.
Working with old code like that, the memories come back to me in bits and pieces, rather than a flood, so it usually takes some time before it dawns on me what I was doing back then.
If you just want to get the program running to use it, might I suggest "compatibility mode".
http://www.howtogeek.com/howto/windows-vista/using-windows-vista-compatibility-mode/
However, if you have a larger, expected useful life of the software, you might want to consider rewriting it. Rewriting it is not anywhere near the complexity or work of the initial write because of a few factors:
Developing the requirements of a program is a substantial part of the required work in making a software package (the requirements are already done)
A lot of the code is already written and only parts may need to be slightly refactored in order to be updated
New library components may be more stable alternatives to parts of the existing codebase
You'll learn how to write current applications with current library facilities
You'll have an opportunity to comment or just generally refactor and cleanup the code (thus making it more maintainable for the anticipated, extended life)
The codebase will be more maintainable/compatible going forward for additional changes in both requirements and operating systems (both because it's updated and because you've had the opportunity to re-understand the entire codebase)
Hope that helps...
I'm creating windows for debugging like this:
cvNamedWindow("a",0); cvShowImage("a", imageA);
cvNamedWindow("b",0); cvShowImage("b", imageB);
cvNamedWindow("c",0); cvShowImage("c", imageC);
OpenCV creates all these windows in the exact same spot, which is not very practical, since only one of them is visible unless you move them around.
Can I make OpenCV automatically arrange the windows so that all of them can be seen (like a tiling window manager)? Or do I have to do this myself using cvMoveWindow?
No, this is impossible - there's no such feature in User Interface (I also was wondering about such functionality a month ago).
You have to manualy set window(s) position by calling MoveWindow - this is the only solution.
I'm trying to make a small game using (free)GLUT. I know that it's old and there are better alternatives, but currently I prefer to stick with it and use it as much as possible. I program with C.
I'm currently trying to make GLUT detect properly all the keys I press.
I use glutKeyboardFunc, glutKeyboardUpFunc, glutSpecialFunc and glutSpecialUpFunc to detect pressed keys and I store their state in a short array I created (I currently have only 5 usable keys, so I just created a specific array for them).
However, while everything works fine for 2 keys or less, the game doesn't detect properly 3 keys or more. While for some keys it detect the combination properly (that actually happens for only 1 specific combination), for others the functions simply don't detect the third key that I press.
I checked my code a few times, and there is nothing special about the combination that does work.
I also made glutKeyboardFunc and glutSpecialFunc directly print every key-press that they receive, and it seems they simply stop working after I press more then 2 keys.
Is it a known issue with GLUT or something? I googled a lot and didn't find anyone with a similar issue.
I am not very into GLUT but as I know, but you should make sure, that your keyboard supports more than 2 input keys at once. This feature is called n-key rollover. This page says, that 2-key rollover may be a common value for some keyboards, but you dont need to trust this source.
I'll clarify a point: The glutKeyBoardFunc is a callback i.e., it is invoked for every key pressed and re-executed over and over again and all the if-else (or switch-case) statements for various key combinations are executed. What it means is this - if you were to press 'A', '->' (right arrow) and 'D' all at once, depending on which key-press event was received first the callback will be executed accordingly. Sometimes with a delay and sometimes the on screen animation may stop momentarily.
GLUT is purely for educational/learning purposes but not good for full blown applications since that's not what it was designed for. You land up using OS specific libs or other languages (e.g., Qt) to embed OpenGL "window" within them and execute the keyboard events etc., The event handling in those (and/or OS specific frameworks) is radically different (and better) than GLUT.
You may want to keep your simultaneous key presses to a minimum. You may augment it with the mouse to get rid of the jerky response/processing...
I'm using Xlib for a project, and I'm trying to get the KeySym relative to a pressed key.
I've got the KeyCode relative to the pressed key, keyboard modifiers and keyboard indicators. I'm referring to this page to understand how to retrieve the correct key, but it must be out of date or something, because my X doesn't behave like that page says.
I've got some questions:
What is MODE SWITCH? How can I see what key is my MODE SWITCH and how can I set it? (via Xlib functions or via a command, it's the same).
That page says that the first 4 KeySyms associated to a KeyCode (found with XGetKeyboardMapping, or shown by xmodmap -pk command) are divided into two groups. MODE SWITCH switches between groups, and within a group the first or the second KeySym is chosen according to modifiers (ie, shift key) or indicators (ie, caps lock). But on my X I can see that if shift is pressed, I switch to the third KeySym, not the second one.
On many european layouts AltGr key is bound to KeySym XS_ISO_Level3_Shift, which doesn't belong to any keyboard modifier (ie, shift, lock, control, mod1, mod2, mod3, mod4 and mod5). When such XS_ISO_Level3_Shift is pressed, the fifth KeySym associated to the KeyCode is chosen. Why? Where can I found some info about this XS_ISO_Level3_Shift and about other keysyms that are actually used, but not documented on Xlib manuals?
It looks like the page you're reading predates Xkb - I'd guess that content is 10-15 years old at least.
See: http://www.xfree86.org/current/XKBproto.pdf
"xmodmap -pm" will show you the modifier keys such as mode switch.
With Xkb, the behavior of basically everything is configurable, I believe. Start looking at /usr/share/X11/xkb/ for example. I don't know a lot about it but hopefully looking at Xkb instead of old docs will get you pointed in the right direction.
Tronche's manual is incomplete. I found more info about keyboard functions in:
1. xlib.pdf
2. xlib html manual at static.cray-cyber.org. This doc is hidden and a bit broken. Links are typed in lowercase, but the actual documents are in uppercase. After correcting the urls in browser it's readable.
PDF is complete I guess. I don't know if [2] is complete too, but for example the chapter 16.2 (sorry, I can't give a link cause my link limit is exceeded) is far longer than in Tronche's doc.
I'm a beginner in understanding xlib, that's what I managed to google out today.