Underdstanding HRESULT in DotNET

  • Thread starter Thread starter Academia
  • Start date Start date
A

Academia

I've been Googling and there is many many hits but I can't find what I want.

I've read at one time how DotNET treats HRESULT but can't find it now.

Does it return HRESULT unchanged or does it check it for error-return or
what?



Thanks for any help
 
I'm doing a SendMessage that returns an HRESULT.

Do I see the "raw" HRESULT of is the "s" field checked and an exception
thrown if "Fail" is indicated?


Thanks to both of you, the sites are very helpful.
 
Academia said:
I'm doing a SendMessage that returns an HRESULT.

Do I see the "raw" HRESULT of is the "s" field checked and an exception
thrown if "Fail" is indicated?
Click to expand...

The exact meaning depends on the message you are sending. Also note that
the return type of 'SendMessage' is 'LRESULT', not 'HRESULT'. Thus the
return value of 'SendMessage' should be typed as 'IntPtr' because 'LRESULT'
is an alias for 'LONG_PTR', which is defined as follows:

\\\
#if defined(_WIN64)
typedef __int64 LONG_PTR;
#else
typedef long LONG_PTR;
#endif
///
 
I'm sure what I'm writing will not run on Win64 so why IntPtr.
I been using Integer since vb.NET didn't allow UInteger when I wrote the
definitions.
Almost all my usage of SendMessage returns a numerical value that fits into
a Integer so why use IntPtr and have to convert the return to Integer?
It's not clear in my mind but I think even if SendMessage returned a
negative value and I had defined the return value as Integer it would work
OK wouldn't it?
I don't know what would happen if it returned a negative value and I had
defined the return as UInteger.
Would CInt() or CType() convert that return to an Integer by just changing
types without doing anything to the bits?




Thanks
 
I had written the top part of the last note (below) before I went to the
sites and it must have been scrolled off the screen when I added the Thanks
and sent it. Actually Wikipedia was clear, except it said:

An opaque result handle defined to be zero for a successful return from a
function and nonzero if error or status information is returned.

Does the successful value have to be zero or can it have a nonzero value as
long as the "s" bit is zero

Why is it called a handle?

Thanks
 
Academia said:
I'm sure what I'm writing will not run on Win64 so why IntPtr.
I been using Integer since vb.NET didn't allow UInteger when I wrote
the definitions.
Almost all my usage of SendMessage returns a numerical value that
fits into a Integer so why use IntPtr and have to convert the return
to Integer?
Click to expand...


Well, IntPtr is the correct translation that works on Win32 and Win64.
Look at the type of the property System.Windows.Forms.Message.Result.
It's IntPtr, too.

If you know it will never run on Win64, you can choose Integer, too.
However, maybe one day you will wish you had chosen Intptr because you
will have to change Integer to Intpr everywhere. Though, that's up to
you to decide, of course.

It's not clear in my mind but I think even if
SendMessage returned a negative value and I had defined the return
value as Integer it would work OK wouldn't it?
Yep

I don't know what would happen if it returned a negative value and I
had defined the return as UInteger.
Click to expand...

Nothing happens. It's just a matter of interpretation. The runtime can't
know whether the MSB is a sign or belongs to the value.
Would CInt() or CType() convert that return to an Integer by just
changing types without doing anything to the bits?
Click to expand...

This fails because the value is > Integer.Maxvalue:

Dim u As UInteger = &H80000000UI
Dim i As Integer = CInt(u)

You could use the Bitconverter instead:

i = BitConverter.ToInt32(BitConverter.GetBytes(u), 0)

- or leave it in an UInteger


If you need it later: ;-)
http://msdn2.microsoft.com/en-us/library/ms973190.aspx



Armin
 
Armin Zingler said:
Well, IntPtr is the correct translation that works on Win32 and Win64.
Look at the type of the property System.Windows.Forms.Message.Result.
It's IntPtr, too.

If you know it will never run on Win64, you can choose Integer, too.
However, maybe one day you will wish you had chosen Intptr because you
will have to change Integer to Intpr everywhere. Though, that's up to
you to decide, of course.
Click to expand...

I going to try changing tomorrow when I'm bright (well at least brighter) -
see how many errors show up after I change the Declare statement. Might as
well do it right.

==========

What I was getting at below is suppose I had some bits in an UInteger and I
want to set the bits in a Integer to match them.

Dim i as Integer = MakeBelieveThisIsAnInteger(&HFFFFFFFF) 'Set i to -1
Is there a managed way to do this.



Thanks
 
I converted the return type of SendMessage to IntPtr. Took many CInt's
becuase the return is often a count of something.

How about WPARAM and LPARAM?

Nazish Ahsan's WebLog suggest they also be somekind of *Ptr.

If I convert to that I can have one delcaration for SendMessage instead of
four but I'll have to replace (...5,6) with (...New IntPtr(5), IntPtr(6)).

Is that what you do?



Thanks

I presently declare
SendMessage(...Integer,Integer)
SendMessage(...IntPtr,Integer)
SendMessage(...Intger,IntPtr)
SendMessage(...IntPtr,IntPtr)
 
Academia said:
I converted the return type of SendMessage to IntPtr. Took many CInt's
becuase the return is often a count of something.

How about WPARAM and LPARAM?

Nazish Ahsan's WebLog suggest they also be somekind of *Ptr.
Click to expand...

Yes, the width of these parameters depends on the system platform too. They
are 32-bit in 32-bit Windows and they ate 64-bit in 64-bit Windows. Thus
'IntPtr' is the suitable type in VB.NET.
If I convert to that I can have one delcaration for SendMessage instead of
four but I'll have to replace (...5,6) with (...New IntPtr(5), IntPtr(6)).

Is that what you do?
Click to expand...

Yes.
 
Academia said:
I converted the return type of SendMessage to IntPtr. Took many
CInt's becuase the return is often a count of something.
Click to expand...

I didn't say you /have to/ do this! :-)
How about WPARAM and LPARAM?
Click to expand...

Look at the properties of System.Windows.Forms.Message.
Nazish Ahsan's WebLog suggest they also be somekind of *Ptr.

If I convert to that I can have one delcaration for SendMessage
instead of four but I'll have to replace (...5,6) with (...New
IntPtr(5), IntPtr(6)).

Is that what you do?
Click to expand...

I don't do anything. I have no computer.

....

Naah, kidding... you're right Intptr(5) etc seems ok.

;-)


Armin
 
Thanks, I'll do that now.




Herfried K. Wagner said:
Yes, the width of these parameters depends on the system platform too.
They are 32-bit in 32-bit Windows and they ate 64-bit in 64-bit Windows.
Thus 'IntPtr' is the suitable type in VB.NET.


Yes.
Click to expand...
 
I've copied Nazish Ahsan's WebLog to my desktop.
I'd like to add that to VS2008's Help.

I looked a little within Help to see if I could find out if Help is
extensible and if so how to add new info but didn't find anything.
Is that possible without an extended effort?

If so, is that the best site to get the conversions for adding from?

Thanks again
 
Thanks for all the presently given help


Armin Zingler said:
I didn't say you /have to/ do this! :-)


Look at the properties of System.Windows.Forms.Message.


I don't do anything. I have no computer.

...

Naah, kidding... you're right Intptr(5) etc seems ok.

;-)


Armin
Click to expand...
 
Suppose SendMessage ends like this:

, ByRef wParam As Integer, ByRef lParam As Integer) As IntPtr

and the call ends like this:

,X,Y) 'X and Y are Integer

Because SendMessage returns X and Y.



How can these lines be changed to use IntPrt?





Thanks
 
Create a Struct and define the return as that

Structure ShortPoint
Public X as Int16
Public Y as Int16
End Structure

Declare Function SendMessage Lib ............ As ShortPoint
 
I think the point of this thread is that the parameters should be typed
IntPtr.
With ByVal I can simply do New IntPrt(X)
But with ByRef that would not work.

Thanks
 
No, you use or return IntPtr when you are passing or returning a *pointer*
to a type. If the return is actually a structure, you don't want IntPtr.
If the return is a pointer to a structure you use IntPtr.
 
Bill McCarthy said:
No, you use or return IntPtr when you are passing or returning a
*pointer* to a type. If the return is actually a structure, you
don't want IntPtr. If the return is a pointer to a structure you use
IntPtr.
Click to expand...

As you know, Sendmessage is a multi purpose function. The values
passed/returned is not always a pointer, it's a plattform specific
integer, which can be a pointer in one case or any other Integer value
in other cases. If you pass a structure containing fixed sized Integers,
it isn't plattform independet anymore, while an Intptr is. The problem
in VB.Net is that we can not do calculations with Intptrs whereas it can
be possible in other languages. For example see Herfried's declaration
of LONG_PTR: It's an __int64 or a long which can be used for
calculations. In most cases this isn't a problem because often Handles
or pointers are passed. 'Academia' now has the problem that the last two
args of SendMessage are IntPtr but he knows these are X- and Y- values
without knowing there size.

Academia, which message do you send? Is it a known (WM_* etc) or a user
defined message?


Armin
 
Back
Top