Handle should be Integer or IntPtr?

[active]

I downloaded the Win32 Library which saved me MUCH work.

Some (All?) of the returned handles are typed int.

As I used them I often changed them in my copy of win32 to IntPtr because an
argument that used it was typed IntPtr.

Now I wonder if a Handle make more sense being an integer or an IntPtr.

I believe it's really an index rather than a pointer so Integer seems to
make more sense.
Any helpful comments would be appreciated,
Cal

[Herfried K. Wagner [MVP]]

* " active" <ac****@REMOVEa-znet.com> scripsit:

I downloaded the Win32 Library which saved me MUCH work.

Some (All?) of the returned handles are typed int.

As I used them I often changed them in my copy of win32 to IntPtr because an
argument that used it was typed IntPtr.

Now I wonder if a Handle make more sense being an integer or an IntPtr.
I prefer 'IntPtr', but it will work with 'Int32' (a/k/a 'Integer') too.
I believe it's really an index rather than a pointer so Integer seems to
make more sense.

It's an identification number.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Tom Shelton]

On 2004-01-17, Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

* " active" <ac****@REMOVEa-znet.com> scripsit:

I downloaded the Win32 Library which saved me MUCH work.

Some (All?) of the returned handles are typed int.

As I used them I often changed them in my copy of win32 to IntPtr because an
argument that used it was typed IntPtr.

Now I wonder if a Handle make more sense being an integer or an IntPtr.

I prefer 'IntPtr', but it will work with 'Int32' (a/k/a 'Integer') too.

I believe it's really an index rather than a pointer so Integer seems to
make more sense.

It's an identification number.

IntPtr... For one important reason - Win64. int maps to System.Int32,
System.IntPtr will take on the default size for the system - 64-bits on
a 64-bit system.

--
Tom Shelton [MVP]

[Mattias Sjögren]

Now I wonder if a Handle make more sense being an integer or an IntPtr.

Preferrably they should be a System.Runtime.InteropServices.HandleRef,
or IntPtr where that doesn't work.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[active]

Thanks for the two replies. That's what I'll do.

I also just noticed that DotNet used IntPtr for the handles I checked.

Isn't that a strong reason for using IntPtr - or is it not?
Thanks again,
Cal
"Tom Shelton" <to*@mtogden.com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...

On 2004-01-17, Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

* " active" <ac****@REMOVEa-znet.com> scripsit:

I downloaded the Win32 Library which saved me MUCH work.

Some (All?) of the returned handles are typed int.

As I used them I often changed them in my copy of win32 to IntPtr because an argument that used it was typed IntPtr.

Now I wonder if a Handle make more sense being an integer or an IntPtr.

I prefer 'IntPtr', but it will work with 'Int32' (a/k/a 'Integer') too.

I believe it's really an index rather than a pointer so Integer seems to make more sense.

It's an identification number.

IntPtr... For one important reason - Win64. int maps to System.Int32,
System.IntPtr will take on the default size for the system - 64-bits on
a 64-bit system.

--
Tom Shelton [MVP]

[Herfried K. Wagner [MVP]]

* " active" <ac****@REMOVEa-znet.com> scripsit:

Thanks for the two replies. That's what I'll do.

I also just noticed that DotNet used IntPtr for the handles I checked.

Isn't that a strong reason for using IntPtr - or is it not?

As Tom said, it will make transition to 64 bit easier because 'IntPtr'
will be 64 bit on 64 bit systems. The 'Handle' property, for example,
is an 'IntPtr' too, that's why I prefer 'IntPtr' for handles.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Jay B. Harlow [MVP - Outlook]]

Cal,
As Tom & Herfried pointed out, its better to use IntPtr as a Handle, as a
Handle is an "opaque" type (it may be a pointer, it may be an index, it may
be a magic cookie) it is really API specific on what the handle actually
represents. Its opaque in that it does not matter what it represents.

I understand that the framework using IntPtr for the reasons that Tom &
Herfried cited.

As the IntPtr help topic itself states "A platform-specific type that is
used to represent a pointer or a handle"
http://msdn.microsoft.com/library/de...ClassTopic.asp

Hope this helps
Jay

" active" <ac****@REMOVEa-znet.com> wrote in message
news:O8**************@TK2MSFTNGP10.phx.gbl...

Thanks for the two replies. That's what I'll do.

I also just noticed that DotNet used IntPtr for the handles I checked.

Isn't that a strong reason for using IntPtr - or is it not?
Thanks again,
Cal
"Tom Shelton" <to*@mtogden.com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...

On 2004-01-17, Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

* " active" <ac****@REMOVEa-znet.com> scripsit:
> I downloaded the Win32 Library which saved me MUCH work.
>
> Some (All?) of the returned handles are typed int.
>
> As I used them I often changed them in my copy of win32 to IntPtr because an> argument that used it was typed IntPtr.
>
> Now I wonder if a Handle make more sense being an integer or an IntPtr.
I prefer 'IntPtr', but it will work with 'Int32' (a/k/a 'Integer') too.
> I believe it's really an index rather than a pointer so Integer seems to> make more sense.

It's an identification number.

IntPtr... For one important reason - Win64. int maps to System.Int32,
System.IntPtr will take on the default size for the system - 64-bits on
a 64-bit system.

--
Tom Shelton [MVP]