SipGetInfo/SIPINFO: Wrong field order?

  • Thread starter Thread starter Benjamin Lukner
  • Start date Start date
B

Benjamin Lukner

Hi!

I've just taken the code from the OpenNetCF Wiki and Alex Feinman's
website to check the state of the SIP and show or hide it.

I use a byte array of 48 bytes length in vb.net to call SipGetInfo.
Before the call I write "48" into the first 4 bytes using
bitconverter.copyto. Then I call SipGetInfo successfully.

But the field fdwflags (bytes 4 to 7) is always "0" and the field cbsize
(bytes 0 to 3) contains the flags instead! The both rectangles are in
the right place.

Is that a malfunction of my Pocket PC or is it the normal behaviour?


Kind regards,

Benjamin Lukner
 
If you use Alex's code it works just fine with the correct data returned. If
you want to convert this to VB then do a direct conversion, you don't need
to use a byte[] when the struct as defined in Alex's code will work
correctly. If you need help with specific items when converting please post
back but it should be fairly straight forward.

Peter
 
Hi!

I've found my "mistake".
The functions have all to be declared as "Private Shared" (that's "private
extern static" in C#).
But why? I can't remember of ever having declared a P/Invoke that way. If I
declare SipShowIM() without "shared", I even get a native exception.


P.S.: Alex, I've found a little mistake in your SipInfo sample:
RECT consists of Left/Top/Right/Bottom, but Drawing.Rectangle is inited via
X/Y/Width/Height but provides also the RECT properties. So Right and Bottom
are miscalculated...

Kind regards,

Benjamin Lukner
 
In VB if you use the "legacy" method of declaring external functions they
are always declared shared:-
Private Declare Function SendMessage Lib "coredll" (ByVal hWnd As IntPtr,
ByVal Msg As Integer, ByVal wParam As Integer, ByVal lParam As Integer) As
Integer

But using the .net method of declaring external functions using the
DllImport attribute you must specify the method is shared e.g.

<DllImport("Coredll")> _

Private Shared Function KernelIoControl(ByVal dwIoControlCode As Int32,
ByVal lpInBuf() As Byte, ByVal nInBufSize As Int32, ByVal outBuf() As Byte,
ByVal nOutBufSize As Int32, ByRef lpBytesReturned As Int32) As Boolean

End Function



You can use the following RECT structure (C#) to convert between the native
RECT and managed Rectangle (excuse the formatting):-

internal struct RECT

{

public int left;

public int top;

public int right;

public int bottom;

public static RECT FromRectangle(Rectangle r)

{

RECT newrect;

newrect.left = r.Left;

newrect.top = r.Top;

newrect.right = r.Right;

newrect.bottom = r.Bottom;

return newrect;

}

public void ToRectangle(Rectangle r)

{

r.X = left;

r.Y = top;

r.Width = right - left;

r.Height = bottom - top;

}

}

Replace the members of the SipInfo struct with RECT and then use the
ToRectangle method to fill a Rectangle from the data.



Peter
 
Peter said:
In VB if you use the "legacy" method of declaring external functions they
are always declared shared:-
But using the .net method of declaring external functions using the
DllImport attribute you must specify the method is shared e.g.

ARGH! OK, it was the first time I used DllImport instead of Declare and
I automatically deleted the word "shared" from the sample I'd found.
You can use the following RECT structure (C#) to convert between the native
RECT and managed Rectangle (excuse the formatting):-

My comment was FYI, but thanks for the sample. :-) I had forgotten to
append one myself.


Kind regards,

Benjamin Lukner
 
Benjamin Lukner said:
Hi!

P.S.: Alex, I've found a little mistake in your SipInfo sample:
RECT consists of Left/Top/Right/Bottom, but Drawing.Rectangle is inited
via X/Y/Width/Height but provides also the RECT properties. So Right and
Bottom are miscalculated...


Thanks for pointing that out. I'll update the sample. I never needed the
bounding rectangle myself and thus never spotted the error.
 
Back
Top