GetCurrentProcess.Id vs GetCurrentProcessId API

[johnboy]

How is the "System.Diagnos tics.Process.Ge tCurrentProcess .Id" different
from the GetCurrentProce ssId API (Kernel32.dll)?

I'm trying to convert code from VB6 to VB.NET and supposedly
GetCurrentProce ss.Id (.NET) is the equivalent of GetCurrentProce ssId
API, but it doesn't work. I placed both in my .NET app to read the
results and I get different numbers. I tried just using the API in .NET
but the function (WD_ConnectPS from ehlapi32.dll) that needs the
process id won't accept it.

How can I get the process id that works in VB6 in VB.NET?

Please help, thank you.

[AMercer]

RE: GetCurrentProce ss.Id vs GetCurrentProce ssId API

> How is the "System.Diagnos tics.Process.Ge tCurrentProcess .Id" different[color=blue]
> from the GetCurrentProce ssId API (Kernel32.dll)?
>
> I'm trying to convert code from VB6 to VB.NET and supposedly
> GetCurrentProce ss.Id (.NET) is the equivalent of GetCurrentProce ssId
> API, but it doesn't work. I placed both in my .NET app to read the
> results and I get different numbers. I tried just using the API in .NET
> but the function (WD_ConnectPS from ehlapi32.dll) that needs the
> process id won't accept it.[/color]

Getting the process id works fine for me - x and y are the same below:

Declare Function GetCurrentProce ssId Lib "kernel32" () As Integer
Dim x As Integer = System.Diagnost ics.Process.Get CurrentProcess. Id
Dim y As Integer = GetCurrentProce ssId()

So, the problem is not with the process id, it is with how you call
WD_ConnectPS in ehlapi32.dll. I guess the declare statement is not right.
You may need to talk to the dll authors for some .net advice - is it NetSoft?

Good luck on what sounds like a challenging conversion.

[johnboy]

Re: GetCurrentProce ss.Id vs GetCurrentProce ssId API

I thought the following was the way to declare APIs in VB.NET:

<DllImport("Ker nel32.dll")> Private Shared Function
GetCurrentProce ssId() As Long
End Function

I noticed that you declared GetCurrentProce ssId as integer and not as
long.
Once I changed every declared function and arguments that were type
"long" in VB6 to "integer" in VB.NET everything worked.

It seems like the difference between VB6 and VB.NET when it comes with
declaring API functions is that when type "long" is used in VB6 and
"integer" is used in VB.NET.

Now, why would GetCurrentProce ssId declared as long return a completely
different number than when declared as integer in VB.NET?

[AMercer]

Re: GetCurrentProce ss.Id vs GetCurrentProce ssId API

> I thought the following was the way to declare APIs in VB.NET:[color=blue]
>
> <DllImport("Ker nel32.dll")> Private Shared Function
> GetCurrentProce ssId() As Long
> End Function
>
> I noticed that you declared GetCurrentProce ssId as integer and not as
> long.
> Once I changed every declared function and arguments that were type
> "long" in VB6 to "integer" in VB.NET everything worked.
>
> It seems like the difference between VB6 and VB.NET when it comes with
> declaring API functions is that when type "long" is used in VB6 and
> "integer" is used in VB.NET.
>
> Now, why would GetCurrentProce ssId declared as long return a completely
> different number than when declared as integer in VB.NET?
>
>[/color]

Actually, my typical api declaration looks like this:

Friend Declare Function GetDesktopWindo w Lib "user32" () As IntPtr

IntPtr (a horrible name for a .net integeral value type) is supposed to cope
with 32-bit and 64 bit issues. The .net doc says this:

"The IntPtr type is designed to be an integer whose size is
platform-specific. That is, an instance of this type is expected to be
32-bits on 32-bit hardware and operating system, and 64-bits on 64-bit
hardware and operating systems."

and this:

"A platform-specific type that is used to represent a pointer or a handle."

I use IntPtr in this context because fxcop suggested it. I suggest you use
fxcop also. It will take a while to get used to it, and some of its
complaints are silly IMO, particularly re naming conventions. But on balance
it points out areas for improvement. I like having no fxcop complaints about
my declare statements.

[Claes Bergefall]

Re: GetCurrentProce ss.Id vs GetCurrentProce ssId API

"johnboy" <johncborges@gm ail.com> wrote in message
news:1145741664 .060479.268510@ u72g2000cwu.goo glegroups.com.. .[color=blue]
>I thought the following was the way to declare APIs in VB.NET:
>
> <DllImport("Ker nel32.dll")> Private Shared Function
> GetCurrentProce ssId() As Long
> End Function
>
> I noticed that you declared GetCurrentProce ssId as integer and not as
> long.
> Once I changed every declared function and arguments that were type
> "long" in VB6 to "integer" in VB.NET everything worked.
>
> It seems like the difference between VB6 and VB.NET when it comes with
> declaring API functions is that when type "long" is used in VB6 and
> "integer" is used in VB.NET.[/color]

Long in VB6 is 32-bit
Long in VB.NET is 64-bit

Integer in VB6 is 16-bit (IIRC)
Integer in VB.NET is 32-bit

So the correct datatype to use is Integer
[color=blue]
> Now, why would GetCurrentProce ssId declared as long return a completely
> different number than when declared as integer in VB.NET?[/color]

Why wouldn't it? The return type is part of the declaration to. Using the
wrong one leads to unpredictable results

/claes