Re: COM interface requires Integer in VB, even though INT_PTR is defined in COM interface
- From: Jeroen Mostert <jmostert@xxxxxxxxx>
- Date: Sat, 19 Apr 2008 00:13:27 +0200
theunissen@xxxxxxxxxxx wrote:
I have a small problem. I have defined some interfaces in a COM dll,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).
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.
So, now I need to cast to Int32. I would also like to compile thisYou 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).
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?
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 thisThen 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.
though.
--
J.
http://symbolsprose.blogspot.com
.
- Follow-Ups:
- References:
- Prev by Date: 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: 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
|
