 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / November 2006Windows Keyboard Hook via JNI
I am frustrated. It is no one's fault but my own and my own ignorance. Once again stupid windows message stuff. I want to monitor keystrokes from inside Java to make a program which invokes functionality from hotkeys. This functionality does not exist in Java - so I will have to use JNI. I find source code for windows hooks - but half the time they don't work, the other half of the time they are so convoluted that I can't extract the information I need. If I can't get it to work in C or C++, then I will never get it to work in JNI. My question is this: Hasn't someone done this? This seems to be a common desired thing - I find people asking about it all over the internet in searches. What I have not found is an idiot proof guide to implementing a Windows Keyboard Hook through JNI or a solid example that I can actually compile. The reason is that I probably don't know how to search for what I am looking for. I am not picky at all - it can be a standalone C program sending UDP messages to my program, or it can be a single DLL that I call through JNI somehow. I'm to the point that a mystery class that I don't even have to look at would be ideal. I don't know windows messaging stuff - and I don't know JNI. :( I have Dev C++ 4 (I don't know subversion) and visual studio.net command line version (because it was free) somewhere I have an old copy of visual c++ 6.0 on a CD - but it might be lost for months. I waste a lot of time not knowing how to compile from the command line - I wish I could find the docs, or a tutorial for that.  SignatureLTP :) > I want to monitor keystrokes from inside Java to make a program which > invokes functionality from hotkeys. This functionality does not exist in > Java - so I will have to use JNI. Menu accellerators do this. It sounds like you need an invisible menu item. JMenuItem item = new JMenuItem(itemName); item.setMnemonic(key); item.setAccelerator(KeyStroke.getKeyStroke(keyevent,0)); item.addActionListener(this); item.renderInvisibleAndYetStillKeepAccelleratorActive(true); P.S. Humour. I'd like to do this last step but haven't yet worked out how. Of course, if you are happy to place your hotkeys in a deep obscure rarely visited menu branch then you are OK. >> I want to monitor keystrokes from inside Java to make a program which >> invokes functionality from hotkeys. This functionality does not exist >> in Java - so I will have to use JNI. This horrid kludge works ... button = new JButton("I'm invisible!"); button.setPreferredSize(new Dimension(0,0)); button.setMnemonic(java.awt.event.KeyEvent.VK_D); button.addActionListener(eventHandler); add(button); It occurs to me that I may have completely misunderstood what Luc wants. The subject line made me think Luc wants to be able to define hotkeys which ... invoke some Java functionality are not tied to any specific Java component work anywhere in the whole application regardless of which Frame or Dialog currently has focus. I'd sprinkle invisible buttons everywhere, until I learn better :-) >>> I want to monitor keystrokes from inside Java to make a program which >>> invokes functionality from hotkeys. This functionality does not exist [quoted text clipped - 17 lines] > > I'd sprinkle invisible buttons everywhere, until I learn better :-) I believe you have misunderstood - as I was well aware that there were ways to monitor keystrokes if one has window focus. What I would like to do is "listen" regardless of which window has focus (even if it is not a java application) and the be able to load a java program from a hotkey. -- LTP :) > I am not picky at all - it can be a standalone C program sending UDP > messages to my program, or it can be a single DLL that I call through JNI > somehow. I'm to the point that a mystery class that I don't even have to > look at would be ideal. As far as I can tell using JNI to hook keyboard events directly from within the main program would be sufficiently non-trivial that it's not a task I would care to undertake. There are lots of hot key manager programs available on the Net; some are free, others are cheap. Maybe you could use one of those. Configure it to launch a tiny helper program which communicates with your main Java program. Come to that, what's wrong with the hot key manager that's built into Windows (as part of the start menu) ? I know it's not very powerful/flexible but it does work, and do you need the extra power enough to make all this running-around-in-circles worth it ? -- chris I wrote: > [...] that it's not a > task I would care to undertake. Re-reading that, I may have given the impression that I thought you were expecting one of us to write the code for you (and that I wasn't any too pleased by the request). I'm sorry if I did come across that way: it was just an unfortunate choice of phrase. -- chris >I wrote: > [quoted text clipped - 6 lines] > just > an unfortunate choice of phrase. It is funny - the first time I read it I thought you said it was sufficiently trivial that you would do it yourself. Maybe that was just wishful thinking -- LTP :) >> I am not picky at all - it can be a standalone C program sending UDP >> messages to my program, or it can be a single DLL that I call through JNI [quoted text clipped - 6 lines] > would > care to undertake. Touchee. The way I see it - is that it is at least twice as hard as it should be and about 3 times harder than I thought it would be. > There are lots of hot key manager programs available on the Net; some are > free, > others are cheap. Maybe you could use one of those. Configure it to > launch a > tiny helper program which communicates with your main Java program. There is a point when one has to realize they are being silly. And using an external hotkey program (which I don't own) to run a C program to trigger my waiting java program is past my threshold of reasonableness. And besides - I wouldn't want the functionality of my program to be based on a hotkey program which I do not own the rights to. > Come to that, what's wrong with the hot key manager that's built into > Windows > (as part of the start menu) ? I know it's not very powerful/flexible but > it > does work, and do you need the extra power enough to make all this > running-around-in-circles worth it ? LOL - not very powerful? It is positively awful! You may find it comical to know that it was my intention to replace window's built in hotkey thingie. I'm not sure if you recall my previous post - but I had mapped CTRL+ALT+F3 to a very simple music search program that I had made and I was complaining about how long it took for a natively compiled JAVA program to start. I want a memory resident application which will start when you press a hotkey. But I don't want to stop there. I would like to develop the standalone hotkey and alarm manager project separately and allow plug-in Java classes. A dictionary/spell checker could be mapped to ALT+CTRL+S, a frequently visited website launcher could be invoked through another key (or perhaps the websites launched directly) Historically when I have used the built in windows hotkey thingie, I would lose all my associations when I reinstalled windows (Every 3-6 months) and then I would lazily setup again CTRL+ALT+W for winamp and CTRL+ALT+N for notepad and CTRL+ALT+C for command prompt. I want to create a hotkey manager which is expandable, allows running classes from an already existing JVM and then allows exporting and importing of hotkey functionalities. For instance, it would be nice while chatting occasionally to invoke an inline HEX AES encryptor. You enter a password, you enter text and cipher text comes out. A simple program would facilitate this, but I would never use it if it were inconvenient to load - I will just send the text and anyone can read it. -- LTP :) > The way I see it - is that it is at least twice as hard as it should be > and about 3 times harder than I thought it would be. Yup. That's why you are using Java isn't it -- instead of becoming a C/Windows programmer ? But the problem comes when Java doesn't have the features you need. In this case, the kinds of people who know about using SetWindowsHookEx(WH_KEYBOARD_HOOK_LL) are not the kinds of people who are likely to want to use the hook to call Java. If they created a pluggable hot key program or library (which didn't just launch user-configuable .exes) at all, then they'd be much more likely to use COM for the pluggable actions. So, you have a choice: Do you want to become a Windows programmer yourself ? If Yes, then start studying ;-) If No, then you have to make do with what you can find. And that means being willing to be flexible about how you glue stuff together. > > There are lots of hot key manager programs available on the Net; some > > are free, [quoted text clipped - 5 lines] > an external hotkey program (which I don't own) to run a C program to > trigger my waiting java program is past my threshold of reasonableness. I'm not sure, but you give the impression that you are (so far) /only/ a Java programmer. If so then you may have an inflated idea of the overhead and "bloat" involved in launching a Windows executable. It is perfectly possible for a process to start, do something, and exit, all in a time comparable with the user's own speed of action/perception. (Remember, I use that architecture myself...) > And besides - I wouldn't want the functionality of my program to be based > on a hotkey program which I do not own the rights to. I can understand that. But you are faced with the choice -- either you write your own hotkey manager (which involves real Windows programming), or you use someone else's. Unless you can afford to pay a Windows programmer to develop the code for you, I don't see that there are any other options. I suppose you might be lucky enough to find an Open Source hot key manager, but I don't know of any myself. And even if you did, you'd still be faced with the architectural problem of how to glue it and your Java stuff together. If you reject the idea of a glue layer implemented as small standalone executables, then you are stuffed... > I want a memory resident application which will start when you press a > hotkey. But I don't want to stop there. I would like to develop the > standalone hotkey and alarm manager project separately Again, I can understand that. It's what I would want myself. But it seems that by insisting that you must have control over the hot key manager, you are essentially cutting yourself off from having hot keys at all. Yet, presumably, you /want/ to be able to launch your Java "programs" now. > Historically when I have used the built in windows hotkey thingie, I would > lose all my associations when I reinstalled windows (Every 3-6 months) Good God man ! Are you a programmer, or just a user ? If you can't figure out a way around a little thing like that.... ;-) (Hint: either write a script to [re]build the shortcuts, or if you don't fancy programming, then just zip up[*] the relevant part of the old shortcut menu folder and copy it across to the new installation). -- chris ([*] The point of zipping is to prevent Windows "helpfully" adjusting the shortcuts for you, which can be a problem if you copy them normally from one place to another.) >> The way I see it - is that it is at least twice as hard as it should be >> and about 3 times harder than I thought it would be. > > Yup. That's why you are using Java isn't it -- instead of becoming a > C/Windows > programmer ? I am not sure if you are insulting me here - but I will concede - Java's purpose seems to make more sense. I worked for 3 years as a C++ programmer doing windows shite. I didn't really understand it then either. Admittedly the microsoft developer tools I used hid a majority of the work from us. There was a lot of cut and paste programming going on, including several very dirty shortcuts which I vehemently disagreed with (after it was explained to me their purpose.) > But the problem comes when Java doesn't have the features you need. In > this [quoted text clipped - 5 lines] > at > all, then they'd be much more likely to use COM for the pluggable actions. No kidding. Trust me, I have discovered this through much travail. The irony is that if I knew how to plug with a hotkey program I would probably know how to write the hotkey program to begin with. > So, you have a choice: Do you want to become a Windows programmer > yourself ? > > If Yes, then start studying ;-) I would love to RTFM - but I need something in tutorial format because I cannot decipher the individual pages when I encounter them. I am sure that using an alternate compiler such as mingw would be great if I understood the underlying principals of windows messaging and the like. Making the minor modifications necessary for operating in a slightly different environment would be trivial! But I approach each problem with a blank look. It is - sad. > If No, then you have to make do with what you can find. And that means > being > willing to be flexible about how you glue stuff together. I would rather not do something than do it wrong. I realize that for exceptionally simple GUIs and programs like I am working with, I could simply run a java "server" and communicate with a C gui via UDP packets. I could also steal someone's source code (I have found at least one program which works, but I am at a loss for understanding it - plus it uses the inexplicable EXE + DLL, which I have read is costly and unnecessary.) The only example I have found which does not use a second DLL is written in MASM - which, although having participated in an assembler programming class, I am again at a loss to decipher. I don't steal source code though. :( And you don't learn from doing that either. >> There is a point when one has to realize they are being silly. And using >> an external hotkey program (which I don't own) to run a C program to >> trigger my waiting java program is past my threshold of reasonableness. > I'm not sure, but you give the impression that you are (so far) /only/ a > Java > programmer. I didn't mean to give that impression. I have programmed in VB, Pascal, C++, C and MIPS assembler and am looking at learning Haskell, which would be my first non imperitive language. I have just never had to deal with low level windows crap. I suppose, and I hate to say this, that I am probably just not a very good programmer. Too bad, too bad - when I was hoping that could be my life. > If so then you may have an inflated idea of the overhead and > "bloat" involved in launching a Windows executable. It is perfectly [quoted text clipped - 4 lines] > architecture > myself...) Be sure you are not just defending your own decisions! Just kdding. I realize that. The cursed Calculator program appears instantly when cached and within about 0.1 seconds when not cached. >> And besides - I wouldn't want the functionality of my program to be based >> on a hotkey program which I do not own the rights to. [quoted text clipped - 15 lines] > executables, > then you are stuffed... I switch too quickly into self loathing mode. If I did more coding and less whining, I might have this thing done by now. >> I want a memory resident application which will start when you press a >> hotkey. But I don't want to stop there. I would like to develop the [quoted text clipped - 7 lines] > presumably, > you /want/ to be able to launch your Java "programs" now. I am glad you could decipher what I meant. Trust me, before I am done there WILL BE an open source, multipurpose, JNI hotkey manager. >> Historically when I have used the built in windows hotkey thingie, I >> would [quoted text clipped - 11 lines] > menu > folder and copy it across to the new installation). A more efficient windows services and start menu organizer has been in my to do list for a long time, but unfortunately it falls lower in priority list than wanting to be able to read and mod WMA, MP3 and FLAC tags which is part of a bigger music searching database application which I would like to be able to conveniently query from an application/class which I intend on being able to invoke from a hotkey ;) > ([*] The point of zipping is to prevent Windows "helpfully" adjusting the > shortcuts for you, which can be a problem if you copy them normally from > one > place to another.) Zipping wouldn't work, because I never know what drive my windows partition will be installed on. Windows doesn't let you specify during install and using registry mods to change drive lettering is highly frowned upon for the system partition even though windows itself should be able to compensate - I have never been daring enough to try it. (I did write the overclockers.com article about remapping a different drive to C for sh*tware applications that insist on being installed there.) As for scripts and the like - I will have to look into it. I haven't much thought about it - maybe just specs on the LNK file format. If I could read it, I could mod it. I have considered making a program to help with my default settings in control panel. I suppose it is little more than an extensive set of registry changes - I would need some way to monitor them as I made them though, so I would know what to change. (A real time registry "spy" logger) -- LTP :) [me:] > > Yup. That's why you are using Java isn't it -- instead of becoming a > > C/Windows programmer ? > > I am not sure if you are insulting me here Not in the least! I was crediting you with good sense. > I worked for 3 years as a C++ programmer doing windows shite. I didn't > really understand it then either. That can be nasty: if the pressure is on to "do the work" without ever really having time to develop an understanding what you are doing, then programming becomes a confusing and distasteful activity[*]. If you are /also/ working via MS's God-awful programming tools, then it must be even worse. Add to that the poor (mostly for historical reasons, I think) design of the MS APIs, then life must be tough, indeed... ([*] I've been in that position a couple of times and absolutely /hated/ it.) I'm not much of a Windows programmer myself (I do know a bit, but I'm not fluent), so any advice I can offer is necessarily suspect. But, FWIW, if you do decide to re-attack Windows programming at the Win32 level, then I suggest you start with the elementary stuff ("elementary" in the mathematical sense). Get hold of a copy of Petzold, and learn what's going on at the message-loop level; totally ignoring MFC and anything and everything that MS's tools try to provide for you. > The irony is that if I knew how to plug with a hotkey program I would > probably know how to write the hotkey program to begin with. <nods/> Or you'd be in a position where you could fairly easily learn how to do so. > I would love to RTFM - but I need something in tutorial format because I > cannot decipher the individual pages when I encounter them. I am sure > that using an alternate compiler such as mingw would be great if I > understood the underlying principals of windows messaging and the like. <nods again/> As far as I know, /nothing/ supplied by MS will help here. It is all either aimed at people who already understand the general terrain (and who only need to fill in the details of some specific API, or deep nitty-gritty stuff about the architecture), or is aimed at beginners. The problem is that when MS write stuff for beginners they nearly always assume that the beginner will want to make maximum use of the tools' damnable "ease of use" features and never even /try/ to understand what's going on -- which completely shuts you out from learning anything useful. Catch 22. I found Petzold's book very helpful in filling in the foundations. (Short review: Basically very good. Explains everything that should be explained. It has far too many long examples for my personal taste (I don't want or need to read pages and pages of C code), but, of course, some people /love/ examples. It has rather an old-fashioned feel, and doesn't cover much of the new stuff, but that's OK (IMO) because it isn't intended to be a /reference/ work (MSDN is pretty good at that) and shouldn't be treated as one.) > I realize that for exceptionally simple GUIs and programs like I am > working with, I could simply run a java "server" and communicate with a C > gui via UDP packets. If you are committed to a no-compromise architecture (which I can respect), then I would /still/ suggest avoiding JNI. I would use two processes, both long-lived: one would be a Windows program that hooked the keyboard and watched for hotkeys, the other would be the main Java program (or programs). The two would communicate over TCP/IP (or perhaps UDP/IP, but I think I'd prefer TCP for this) Hooking Windows keyboard events seems to be pretty arcane, but from what I can tell from sniffing around the net, the best method is by using SetWindowsHookEx(WH_KEYBOARD_HOOK_LL). That, as I understand it, doesn't require the strange DLL stuff (nor the even stranger architectural reason for that requirement -- that Windows will map your hook code into the address space of every target process !). However it does require a standalone Windows event loop. You /can/ create one of those in JNI, by forking a new thread to run the loop, but in the end you'd end up with almost exactly the same architecture -- two independent processing loops communicating via some form of IPC -- but expressed in a significantly more awkward way. Also the two-processes approach would make it a lot easier to develop/debug the hook program separately from the main Java code (remember that any fault in that will probably require a hard reboot to fix). > I suppose, and I hate to say this, that I am probably just not a very good > programmer. Too bad, too bad - when I was hoping that could be my life. You might be right, but I don't see any reason to suppose that you are. Judge yourself by what you can learn, and by how well you learn it, when you are in a /position/ to learn. Getting stuck in "copy paste" land on an ugly C/Windows project does not count as such. In fact it doesn't count as anything much, except a few wasted years and some Good Stuff to put in your CV. If you can compile a hello world program in C, using MS or anyone else's compiler, and have the right book handy, then that's all the tooling you'll need to start learning how to program Windows as a /real/ programmer (not an MS slave). (I assume a moderate knowledge of C itself). When you get to the point where you can use the Win32 API to open a window, show a few lines of text or some simple graphics, and respond to a mouse-click or keyboard event by doing something sensible, then you'll have got the basics. By "basics" I mean that you'd have a fundamental understanding of how a Windows program works. From there on in, understanding almost any example, or using any given API is just a matter of working your way through the sludge of MS API's -- a distinctly wearisome task, but intricate rather than intrinsically difficult. That sludge is why people with sense avoid Windows programming whenever they can... Note that COM is (at least conceptually, and in my opinion) independent from the Win32 stuff -- it would have to be learned separately if you needed it. > As for scripts and the like - I will have to look into it. I haven't much > thought about it - maybe just specs on the LNK file format. If I could > read it, I could mod it. A word of warning: I have only ever found one "spec" (actually a reverse-engineering) of the LNK format. It was out of date and incorrect (as became immediately obvious comparing a binary dump of a real LNK file with the "spec"). As far as I know, the /only/ MS-sanctioned way to create links is programmatically via the WScript COM object, as in the following WSH script: ======== makelink.js ========== function makeDesktopLink(name, to) { var shell = WScript.CreateObject("WScript.Shell"); var desktop = shell.SpecialFolders("Desktop"); var link = shell.CreateShortcut(desktop + "\\" + name + ".lnk"); link.TargetPath = to; link.Save(); } makeDesktopLink("ScitTE", "C:\\Win32App\\Scite\\wscite168\\wscite\\SciTE.exe"); ============================ For a reasonable-looking intro to scripting in this way: http://www.code-magazine.com/article.aspx?quickid=0001061&page=1 -- chris > [me:] >> > Yup. That's why you are using Java isn't it -- instead of becoming a [quoted text clipped - 3 lines] > > Not in the least! I was crediting you with good sense. Ah ok >> I worked for 3 years as a C++ programmer doing windows shite. I didn't >> really understand it then either. [quoted text clipped - 10 lines] > life > must be tough, indeed... 6 months writing mid to high level Serial communication functions to find out 3 years later there was a serious fundamental flaw in the low level stuff, some error handling procedure which simply began discarding data if the processor got backlogger (very likely on a 133 mhz pentium), the only stuff I had not rewritten from scratch. Boy did I feel dumb - but it explained a lot of those truly odd lost data problems. > ([*] I've been in that position a couple of times and absolutely /hated/ > it.) I didn't hate it. Sure beats cleaning toilets. > I'm not much of a Windows programmer myself (I do know a bit, but I'm not > fluent), so any advice I can offer is necessarily suspect. But, FWIW, if [quoted text clipped - 8 lines] > try to > provide for you. Right now my entire means of living is sitting in two large coins on my desk - when I get a bit more I will find this book of which you speak. >> The irony is that if I knew how to plug with a hotkey program I would >> probably know how to write the hotkey program to begin with. > > <nods/> Or you'd be in a position where you could fairly easily learn how > to > do so. It sounds less funny that way > <nods again/> As far as I know, /nothing/ supplied by MS will help here. > It [quoted text clipped - 11 lines] > you > out from learning anything useful. Catch 22. Oh good - then it is not just me! > If you are committed to a no-compromise architecture (which I can > respect), [quoted text clipped - 3 lines] > watched > for hotkeys, the other would be the main Java program (or programs). Ok - sometimes it is best to blindly trust the mentor. This was my original idea anyway - JNI was supposed to simplify synchronization and prevent rogue processes. > For a reasonable-looking intro to scripting in this way: > http://www.code-magazine.com/article.aspx?quickid=0001061&page=1 I will look into this. -- LTP :) > > If you are committed to a no-compromise architecture (which I can > > respect), [quoted text clipped - 5 lines] > > Ok - sometimes it is best to blindly trust the mentor. Or maybe you should find a different mentor ;-) I've only just now remembered an interesting post here by Jean-Francois Briere on 1st August this year which gives a complete example of setting a keyboard hook using JNI. I haven't tried his code, and as I mentioned I'm not a WinAPI expert, but as far as I can see it all looks correct, and takes no "unsafe" short-cuts (bearing in mind that it's a stripped down example). I don't know how much sense it'll make without a background knowledge of Windows event loops, JNI, and the theading isssues when combining them, but it's a start, and could maybe give your researches a tighter focus. -- chris >> Ok - sometimes it is best to blindly trust the mentor. > [quoted text clipped - 9 lines] > that > it's a stripped down example). Hehe - YAY! I found it on google groups. I will get it figured out! > I don't know how much sense it'll make without a background knowledge of > Windows event loops, JNI, and the threading issues when combining them, > but > it's a start, and could maybe give your researches a tighter focus. Hopefully none at all. Granted - I can't very well make a commercial product using someone else's code, no matter how small - but if it comes down to it I can learn the crap and get it working - for now something that works in any shape or form will be good for sh.ts and giggles ;) Having a working example helps a lot - I will compile it later. -- LTP :) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.