

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
9 messages in net.java.dev.jna.usersRe: [jna-users] callback at keyboard ...| From | Sent On | Attachments |
|---|---|---|
| Michele Croci | Nov 5, 2007 12:58 am | |
| Timothy Wall | Nov 5, 2007 5:56 am | |
| Michele Croci | Nov 5, 2007 10:17 am | |
| Timothy Wall | Nov 5, 2007 10:41 am | |
| Timothy Wall | Nov 5, 2007 10:45 am | |
| Michele Croci | Nov 6, 2007 2:45 am | |
| Timothy Wall | Nov 6, 2007 6:58 am | |
| Michele Croci | Nov 7, 2007 2:53 am | |
| Timothy Wall | Nov 7, 2007 6:32 am | .c |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] callback at keyboard event | Actions... |
|---|---|---|
| From: | Timothy Wall (twal...@dev.java.net) | |
| Date: | Nov 5, 2007 5:56:55 am | |
| List: | net.java.dev.jna.users | |
See comments below.
On Nov 5, 2007, at 3:58 AM, Michele Croci wrote:
Hi all,
i have taken an example found in the mailing-list archive for a callback for a keyboard event. The example doesn't worked, so I have completed it and now works a little better, but as soon as the callback procedure is called the JVM crashes.
Can you provide the stack dump of the crash?
I tried that example as well, and found that the regular keyboard hook didn't work (which is why it isn't yet in the contrib area of the project). I didn't have time to spend playing around with it to find the problem.
public class Keyboard {
Pointer hinst; KeyboardProc kbListener; Pointer handle;
public Keyboard() { hinst = Kernel32.INSTANCE.GetModuleHandleW(null);
kbListener = new KeyboardProc() { public int callback(int code, WPARAM wParam, LPARAM lParam) { System.out.println("keyboard callback code: " +code + " wParam "+ wParam + " lParam "+lParam );
Is this next statement where the crash occurs? If so, then that is the likely candidate for a) improper calling convention, b) improper argument sizes, or c) invalid parameter values.
return User32.INSTANCE.CallNextHookEx(handle, code, wParam, lParam); } }; handle = User32.INSTANCE.SetWindowsHookExW (User32.WH_KEYBOARD_LL, kbListener, hinst, 0); }
protected void finalize() throws Throwable { User32.INSTANCE.UnhookWindowsHookExW(handle); super.finalize(); }
public static void main(String[] args) { System.out.println("Start."); Keyboard instance = new Keyboard(); BufferedReader br = new BufferedReader( new InputStreamReader( System.in ) ); try { boolean go = true; while(go){ MSG msg = new MSG(); go = User32.INSTANCE.GetMessageW (msg,null,0,0); //fUser32.INSTANCE.DispatchMessageW(msg);
I assume this is part of debugging, since if you don't dispatch the message, your callback will never be called.
} br.readLine(); } catch( IOException ex ) {} System.out.println("Done."); }
public interface KeyboardProc extends StdCallCallback { int callback(int code, WPARAM wParam, LPARAM lParam); } }
// LPARAM and WAPRAM def:
public static class LPARAM extends LONG_PTR { public LPARAM() { this(0); } public LPARAM(long value) { super(value); } } public static class WPARAM extends IntegerType { public WPARAM() { this(0); } public WPARAM(long value) { super(Pointer.SIZE, value); } }
The function callback is called only one, then the JVM crashes. note that if I call SetWindowsHookExW with WH_KEYBOARD no callback function is called.
This may have to do with whether you use javaw.exe or java.exe, since one is a GUI-based invocation and the latter is a console-based invocation. The console-based java.exe may not set things up properly for handling windows messages. Just a guess, though.
The crash is maybe caused by a incorrect type conversion?
That's usually the problem. Double-check your parameters for the proper sizes. The other problem is often using Library where StdCallLibrary is called for.
Note: If you're going to explicitly use the "W"-suffixed methods, you will need to explicitly use WString where LPTCSTR is requested. The DEFAULT_OPTIONS object in the W32API interface sets things up to automatically map functions to the "W"-suffixed methods, and also automatically convert java.lang.String to the appropriate type. In your case, java.lang.String will be converted to a "char*"-based C string, rather than a "wchar_t*"-based wide string, which is what the "W"-suffixed methods expect.








.c