HWND <---> int conversion

[Markus KARG]

Sometimes we need to convert a HWND into an int (and vice versa).

 

Example (1): Declaring Win32's HWND_MESSAGE constant as "-3".

Example (2): Providing a HWND to a function that actually is typed "int" by another framework (here: com4j).

 

While we actually solved both by accessing the native pointer, we're not pleased with our current solution (static conversion methods). We could contribute some code lines to JNA which allows to write this instead:

 

(1) HWND HWND_MESSAGE = new HWND(3);

(2) int i = hWnd.asInt();

 

(in fact, this should be part of HANDLE actually instead of only HWND)

 

Shall we do this, or will it foil some particular design ideas of JNA? :-)

[Daniel Doubrovkine]

You have to be really careful with what Integer is on various platforms, these handles are really pointer types, they are addresses. Is it really OK to convert them to int? Is it really OK to consume then as ints?

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

dB. | Moscow - Geneva - Seattle - New York
dblock.org - @dblockdotorg

[Markus KARG]

This is what we are uncertain about. Where did you learn that HWND actually is a pointer (we always thought it is a hash for a windows-internal resources hash table)?

 

We noticed that several C / Win32 based software converts handles to int from time to time. This is where we discovered that when rewriting a C based software talking to a COM server: com4j produced "int" for "HWND" from the COM server's TLB. So we had the need to create HWND in JNA, then convert it to int.

 

You're right, maybe it's better if we stick with having this static code internally in our project, not publishing it on github.

[Daniel Doubrovkine]

In Java an Int is a 32-bit signed integer. On Windows HANDLE is typedef-ed to LPVOID, which is a pointer. So by design converting LPVOID into an int *will* lose data. Now, an HWND could very well be a 32-bit hash cast and it just happens to work, but I wouldn't rely on it.

This could be helpful: http://stackoverflow.com/questions/2024895/how-should-i-handle-cast-from-void-to-int-loses-precision-when-compiling

cheers

dB.

--

You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Markus KARG]

You are right with that. We need to check why com4j creates "int" for "HWND". Possibly there is a bug in the TLB, we have check that.

 

Thanks!

-Markus