Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- From: theunissen@xxxxxxxxxxx
- Date: Fri, 18 Apr 2008 16:21:03 -0700 (PDT)
On Apr 18, 3:26 pm, theunis...@xxxxxxxxxxx wrote:
On Apr 18, 3:13 pm, Jeroen Mostert <jmost...@xxxxxxxxx> wrote:
theunis...@xxxxxxxxxxx wrote:
I have a small problem. I have defined some interfaces in a COM dll,
and have defined some parameters in these interfaces as INT_PTR. I
thought that when I import the COM dll in Visual Basic.NET that I can
use IntPtr as the type for these parameters, but the intellisense
shows me that the parameters in the interfaces have been changed to
Integer instead of the VB type IntPtr.
The reason this doesn't work is that INT_PTR is just a typedef for a
platform-specific size, so by the time the import runs it just sees an int
(or an __int64 when you're importing the 64-bit version).
So, now I need to cast to Int32. I would also like to compile this
code for x64, wherease I need to cast it to Int64. Is this normal
behavior and do I need to distinguish between x86 and x64 mode when
passing arguments to a COM interface that has INT_PTR as one of its
parameters, or is there another trick to have the interfaces become
compatible with the Visual Basic IntPtr type, regardless of x86 or
x64?
You could declare the type as HANDLE. This should cause the import to use a
platform-dependent IntPtr. There may be other, more logical types that will
map to IntPtr, but HANDLE is the one that I know works (at least for C#; it
should work the same for VB as the import is AFAIK language-independent)..
Note, however, that the unmanaged code can still only be compiled for one
platform only (as opposed to the managed code, which is platform-agnostic
and will be JIT-compiled for the platform unless you override it).
Marshaling will take care of the size difference, so it's actually possible
for (say) 64-bit code to use a 32-bit COM server and have this work -- but
not in-process, because 64-bit apps can't load 32-bit DLLs and vice versa.
You will likely need to maintain two build configurations at least for the
unmanaged code.
Take a good look at whether you actually need x64 support, as it can often
*decrease* performance. x86 applications will run just fine on x64 systems;
you should only go for 64-bit if your application can really benefit from
the increased address space. Otherwise, it's worth setting up things so that
building for 64-bit won't be too much of a bother, but not worth actually
creating builds.
Also, what happens with "Option Strict Off"? I prefer not to use this
though.
Then don't use it. "Option Strict Off" can never be used to circumvent
actual type correctness, it just relaxes the need for casts by practically
eliminating type safety. Your code will just fail at runtime rather than at
compile time if it's not correct.
--
J.http://symbolsprose.blogspot.com
Thank you so much for the explanation. Also for the HANDLE tip.
I do have different configurations for both, 32 and 64 bit. We're
using 64-bit to support large (> 2 or 4 GB) image handling for medical
apps. Just codewise I am hoping to do as less as possible to
differentiate between the different platforms. So, thanks so much for
your help.
Michel- Hide quoted text -
- Show quoted text -
hmm...
It seems HANDLE is not supported in IDL.
The IDL compiler complains and says:
error MIDL2139 : type of the parameter cannot derive from void or void
* : [ Type 'HANDLE' ( Parameter 'nBinArrayAddress' ) ]
Not sure what to do.
.
- Follow-Ups:
- References:
- COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- From: theunissen
- Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- From: Jeroen Mostert
- Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- From: theunissen
- COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- Prev by Date: Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- Next by Date: Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- Previous by thread: Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- Next by thread: Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- Index(es):
Relevant Pages
|
