Probably a noob question but interop isn't one of my strong points yet.
Aside from limiting the number of overloads is there any reason I should declare my DllImports like:
[DllImport("user32.dll")]
public static extern int SendMessage(IntPtr hWnd, int msg, int wParam, IntPtr lParam);
And use them like this:
IntPtr lParam = Marshal.AllocCoTaskMem(Marshal.SizeOf(formatrange));
Marshal.StructureToPtr(formatrange, lParam, false);
int returnValue = User32.SendMessage(_RichTextBox.Handle, ApiConstants.EM_FORMATRANGE, wParam, lParam);
Marshal.FreeCoTaskMem(lParam);
Rather than creating a targeted overload:
[DllImport("user32.dll")]
public static extern int SendMessage(IntPtr hWnd, int msg, int wParam, ref FORMATRANGE lParam);
And using it like:
FORMATRANGE lParam = new FORMATRANGE();
int returnValue = User32.SendMessage(_RichTextBox.Handle, ApiConstants.EM_FORMATRANGE, wParam, ref lParam);
The by ref overload ends up being easier to use but I'm wondering if there is a drawback that I'm not aware of.
Edit:
Lots of great info so far guys.
#P Daddy: Do you have an example of basing the struct class off an abstract (or any) class? I changed my signature to:
[DllImport("user32.dll", SetLastError = true)]
public static extern int SendMessage(IntPtr hWnd, int msg, int wParam, [In, Out, MarshalAs(UnmanagedType.LPStruct)] CHARFORMAT2 lParam);
Without the In, Out, and MarshalAs the SendMessage (EM_GETCHARFORMAT in my test) fail. The above example works well but if I change it to:
[DllImport("user32.dll", SetLastError = true)]
public static extern int SendMessage(IntPtr hWnd, int msg, int wParam, [In, Out, MarshalAs(UnmanagedType.LPStruct)] NativeStruct lParam);
I get a System.TypeLoadException that says the CHARFORMAT2 format is not valid (I'll try and capture it for here).
The exception:
Could not load type 'CC.Utilities.WindowsApi.CHARFORMAT2' from assembly 'CC.Utilities, Version=1.0.9.1212, Culture=neutral, PublicKeyToken=111aac7a42f7965e' because the format is invalid.
The NativeStruct class:
public class NativeStruct
{
}
I've tried abstract, adding the StructLayout attribute, etc. and I get the same exception.
[StructLayout(LayoutKind.Sequential)]
public class CHARFORMAT2: NativeStruct
{
...
}
Edit:
I didn't follow the FAQ and I asked a question that can be discussed but not positively answered. Aside from that there has been lot's of insightful information in this thread. So I'll leave it up to the readers to vote up an answer. First one to over 10 up-votes will be the answer. If no answer meets this in two days (12/17 PST) I'll add my own answer that summarizes all the yummy knowledge in the thread :-)
Edit Again:
I lied, accepting P Daddy's answer because he is the man and has been a great help (he has a cute little monkey too :-P)
If the struct is marshalable without custom processing, I greatly prefer the latter approach, where you declare the p/invoke function as taking a ref (pointer to) your type. Alternatively, you can declare your types as classes instead of structs, and then you can pass null, as well.
[StructLayout(LayoutKind.Sequential)]
struct NativeType{
...
}
[DllImport("...")]
static extern bool NativeFunction(ref NativeType foo);
// can't pass null to NativeFunction
// unless you also include an overload that takes IntPtr
[DllImport("...")]
static extern bool NativeFunction(IntPtr foo);
// but declaring NativeType as a class works, too
[StructLayout(LayoutKind.Sequential)]
class NativeType2{
...
}
[DllImport("...")]
static extern bool NativeFunction(NativeType2 foo);
// and now you can pass null
<pedantry>
By the way, in your example passing a pointer as an IntPtr, you've used the wrong Alloc. SendMessage is not a COM function, so you shouldn't be using the COM allocator. Use Marshal.AllocHGlobal and Marshal.FreeHGlobal. They're poorly named; the names only make sense if you've done Windows API programming, and maybe not even then. AllocHGlobal calls GlobalAlloc in kernel32.dll, which returns an HGLOBAL. This used to be different from an HLOCAL, returned by LocalAlloc back in the 16-bit days, but in 32-bit Windows they are the same.
The use of the term HGLOBAL to refer to a block of (native) user-space memory just kind of stuck, I guess, and the people designing the Marshal class must not have taken the time to think about how unintuitive that would be for most .NET developers. On the other hand, most .NET developers don't need to allocate unmanaged memory, so....
</pedantry>
Edit
You mention you're getting a TypeLoadException when using a class instead of a struct, and ask for a sample. I did up a quick test using CHARFORMAT2, since it looks like that's what you're trying to use.
First the ABC1:
[StructLayout(LayoutKind.Sequential)]
abstract class NativeStruct{} // simple enough
The StructLayout attribute is required, or you will get a TypeLoadException.
Now the CHARFORMAT2 class:
[StructLayout(LayoutKind.Sequential, Pack=4, CharSet=CharSet.Auto)]
class CHARFORMAT2 : NativeStruct{
public DWORD cbSize = (DWORD)Marshal.SizeOf(typeof(CHARFORMAT2));
public CFM dwMask;
public CFE dwEffects;
public int yHeight;
public int yOffset;
public COLORREF crTextColor;
public byte bCharSet;
public byte bPitchAndFamily;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst=32)]
public string szFaceName;
public WORD wWeight;
public short sSpacing;
public COLORREF crBackColor;
public LCID lcid;
public DWORD dwReserved;
public short sStyle;
public WORD wKerning;
public byte bUnderlineType;
public byte bAnimation;
public byte bRevAuthor;
public byte bReserved1;
}
I've used using statements to alias System.UInt32 as DWORD, LCID, and COLORREF, and alias System.UInt16 as WORD. I try to keep my P/Invoke definitions as true to SDK spec as I can. CFM and CFE are enums that contain the flag values for these fields. I've left their definitions out for brevity, but can add them in if needed.
I've declared SendMessage as:
[DllImport("user32.dll", CharSet=CharSet.Auto)]
static extern IntPtr SendMessage(
HWND hWnd, MSG msg, WPARAM wParam, [In, Out] NativeStruct lParam);
HWND is an alias for System.IntPtr, MSG is System.UInt32, and WPARAM is System.UIntPtr.
[In, Out] attribute on lParam is required for this to work, otherwise, it doesn't seem to get marshaled both directions (before and after call to native code).
I call it with:
CHARFORMAT2 cf = new CHARFORMAT2();
SendMessage(rtfControl.Handle, (MSG)EM.GETCHARFORMAT, (WPARAM)SCF.DEFAULT, cf);
EM and SCF are enums I've, again, left out for (relative) brevity.
I check success with:
Console.WriteLine(cf.szFaceName);
and I get:
Microsoft Sans Serif
Works like a charm!
Um, or not, depending on how much sleep you've had and how many things you're trying to do at once, I suppose.
This would work if CHARFORMAT2 were a blittable type. (A blittable type is a type that has the same representation in managed memory as in unmanaged memory.) For instance, the MINMAXINFO type does work as described.
[StructLayout(LayoutKind.Sequential)]
class MINMAXINFO : NativeStruct{
public Point ptReserved;
public Point ptMaxSize;
public Point ptMaxPosition;
public Point ptMinTrackSize;
public Point ptMaxTrackSize;
}
This is because blittable types are not really marshaled. They're just pinned in memory—this keeps the GC from moving them—and the address of their location in managed memory is passed to the native function.
Non-blittable types have to be marshaled. The CLR allocates unmanaged memory and copies the data between the managed object and its unmanaged representation, making the necessary conversions between formats as it goes.
The CHARFORMAT2 structure is non-blittable because of the string member. The CLR can't just pass a pointer to a .NET string object where a fixed-length character array is expected to be. So the CHARFORMAT2 structure must be marshaled.
As it would appear, for correct marshaling to occur, the interop function must be declared with the type to be marshaled. In other words, given the above definition, the CLR must be making some sort of determination based on the static type of NativeStruct. I would guess that it's correctly detecting that the object needs to be marshaled, but then only "marshaling" a zero-byte object, the size of NativeStruct itself.
So in order to get your code working for CHARFORMAT2 (and any other non-blittable types you might use), you'll have to go back to declaring SendMessage as taking a CHARFORMAT2 object. Sorry I led you astray on this one.
Captcha for the previous edit:
the whippet
Yeah, whip it good!
Cory,
This is off topic, but I notice a potential problem for you in the app it looks like you're making.
The rich textbox control uses standard GDI text-measuring and text-drawing functions. Why is this a problem? Because, despite claims that a TrueType font looks the same on screen as on paper, GDI does not accurately place characters. The problem is rounding.
GDI uses all-integer routines to measure text and place characters. The width of each character (and height of each line, for that matter) is rounded to the nearest whole number of pixels, with no error correction.
The error can easily be seen in your test app. Set the font to Courier New at 12 points. This fixed-width font should space characters exactly 10 per inch, or 0.1 inches per character. This should mean that, given your starting line width of 5.5 inches, you should be able to fit 55 characters on the first line before wrap occurs.
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123
But if you try, you'll see that wrap occurs after only 54 characters. What's more the 54th character and part of the 53rd overhang the apparent margin shown on the ruler bar.
This assumes you have your settings at standard 96 DPI (normal fonts). If you use 120 DPI (large fonts), you won't see this problem, although it appears that you size your control incorrectly in this case. You also won't likely see this on the printed page.
What's going on here? The problem is that 0.1 inches (the width of one character) is 9.6 pixels (again, using 96 DPI). GDI doesn't space characters using floating point numbers, so it rounds this up to 10 pixels. So 55 characters takes up 55 * 10 = 550 pixels / 96 DPI = 5.7291666... inches, whereas what we were expecting was 5.5 inches.
While this will probably be less noticeable in the normal use case for a word processor program, there is a likelihood of instances where word wrap occurs at different places on screen versus on page, or that things don't line up the same once printed as they did on screen. This could turn out to be a problem for you if this is a commercial application you're working on.
Unfortunately, the fix for this problem is not easy. It means you'll have to dispense with the rich textbox control, which means a huge hassle of implementing yourself everything it does for you, which is quite a lot. It also means that the text drawing code you'll have to implement becomes fairly complicated. I've got code that does it, but it's too complex to post here. You might, however, find this example or this one helpful.
Good luck!
1 Abstract Base Class
I've had some fun cases where a parameter is something like ref Guid parent and the corresponding documentation says:
"Pointer to a GUID specifying the parent. Pass a null pointer to use [insert some system-defined item]."
If null (or IntPtr.Zero for IntPtr parameters) really is an invalid parameter, then you're fine using a ref parameter - maybe even better off since it's extra clear exactly what you need to pass.
If null is a valid parameter, you can pass ClassType instead of ref StructType. Objects of a reference type (class) are passed as a pointer, and they allow null.
No, you cannot overload SendMessage and make the wparam argument an int. That will make your program fail on a 64-bit version of the operating system. It has to be a pointer, either IntPtr, a blittable reference or an out or ref value type. Overloading the out/ref type is otherwise fine.
EDIT: As the OP pointed out, this is not actually a problem. The 64-bit function calling convention passes the first 4 arguments through registers, not the stack. There is thus no danger of stack mis-alignment for the wparam and lparam arguments.
I don't see any drawbacks.
By-ref is often enough for simple type and simple structure.
IntPtr should be favored if the structure has a variable-size or if you want to do custom processing.
Using ref is simpler and less error-prone than manipulating pointers manually, so I see no good reason for not using it... Another benefit of using ref is that you don't have to worry about freeing unmanaged allocated memory
Related
When I use the code analysis feature in my Visual Studio project, I'm getting a unexpected CA1901 warning for ChildWindowFromPointEx and also for RealChildWindowFromPoint, at their parameters of type POINT.
I just defined a structure with name NativePoint with X and Y fields as Int32 type, which I'm using as an equivalent for those POINT parameters.
I understand what the portability means in terms of value size when running under x86 or x64, however, in this case I'm not sure how to solve this warning, because I'm using the same NativePoint structure for POINT parameters of other functions like for example: ChildWindowFromPoint, ClientToScreen, GetCursorPos and many others, and code analysis is not warning about them, and they work when running on a x86 and x64 process.
In fact, ChildWindowFromPoint and ChildWindowFromPointEx only seems to differ by one additional parameter, both takes the same POINT structure as parameter so I don't understand why ChildWindowFromPointEx is warning about portability issues while for ChildWindowFromPoint is all fine.
My question is: in C# or VB.NET, how do I properly fix (not suppress) this warning for ChildWindowFromPointEx and RealChildWindowFromPoint functions?. Maybe I need to define another different NativePoint struct with different field types only to use with these two functions?. But why these two functions throws a warning while for ChildWindowFromPoint does not if both takes the same POINT (my NativePoint) structure?.
Note that I get the same warning for those two functions if I use System.Drawing.Point structure, but only for those two.
[DllImport("user32.dll", EntryPoint="ChildWindowFromPointEx", SetLastError=false)]
public extern static IntPtr ChildWindowFromPointEx(IntPtr hwndParent,
NativePoint point,
uint flags);
[DllImport("user32.dll", EntryPoint="RealChildWindowFromPoint", SetLastError=false)]
public extern static IntPtr RealChildWindowFromPoint(IntPtr hwndParent,
NativePoint point);
[StructLayout(LayoutKind.Sequential)]
public struct NativePoint {
public int X;
public int Y;
}
After poking around in the responsible analysis assembly, there is a mismatch between the Windows API documentation and the data set used by the analysis plugin.
The rule thinks RealChildWindowFromPoint should have have 3 parameters of each 4 bytes, and ChildWindowFromPointEx 4 parameters of each 4 bytes on x86. ChildWindowFromPoint on the other hand is listed as having one 4 byte parameter and one 8 byte parameter as expected.
Indeed, declaring RealChildWindowFromPoint this way seems to satisfy the code analysis, but I don't know enough about the Windows API calling conventions to say whether this is actually a valid way of calling that method:
[DllImport("user32.dll", EntryPoint = "RealChildWindowFromPoint", SetLastError = false)]
public static extern IntPtr RealChildWindowFromPoint(IntPtr hwndParent, int x, int y);
Considering that rules for RealChildWindowFromPoint and ChildWindowFromPointEx are missing data for the return value size as well as x64 declarations, while the data for ChildWindowFromPoint is complete, I would assume that this is simply a mistake in the data rather than an intentional recommendation.
RegSetValueEx has the following P/Invoke signature:
[DllImport("advapi32.dll", SetLastError = true)]
static extern uint RegSetValueEx(
UIntPtr hKey,
[MarshalAs(UnmanagedType.LPStr)]
string lpValueName,
int Reserved,
RegistryValueKind dwType,
IntPtr lpData,
int cbData);
The IntPtr lpData parameter can be a pain to work with. To pass a string value, I need to call one of the Marshall.StringToHGlobal functions and then release it when I'm done. My code can be simpler if I change the type of the lpData parameter to [MarshalAs(UnmanagedType.LPStr)]String lpData. This seems to work and I can imagine that behind the scenes the marshalling code is doing exactly what I would do to get an IntPtr. I haven't been able to find any definitive statements if this is legal or not. Can anyone provide one?
[Yes, I know there is managed code to interface with the registry. In my particular case I can't use it, and even if I could I would still be interested in the answer in general]
Yes, this is a perfectly normal and acceptable technique in pinvoke. Just about any winapi function argument of type BYTE*, PVOID, LPARAM lends itself to a customized [DllImport] declaration. A string, array or struct is the usual equivalent C# parameter type. Particularly useful when you declare SendMessage().
Not where it ends, you can also readily take advantage of the C# language allowing method overloads. In other words, you can write any number of RegSetValueEx() declarations with different types for the lpData argument. They all map to the same native function so nothing else you have to do. A practical example is here.
You just have to make sure that the value you pass after marshalling has the expected byte values. Beware that mistakes tend to be hard to debug, you might still want to marshal manually if the call doesn't pan out. One quirk is certainly notable for this question, you always want to use CharSet = CharSet.Unicode in the declaration, calling the ANSI version (RegSetValueExA) is not useful. Now you can also add ExactSpelling = true.
I'm working on a Vulkan wrapper for C# (like I'm sure many people are) and I'm having a bit of a problem with vkGetPhysicalDeviceFeatures it either doesn't return data, or throws Access Violations
Unanaged Side - Signature:
The signature from the spec is this:
void vkGetPhysicalDeviceFeatures(
VkPhysicalDevice physicalDevice,
VkPhysicalDeviceFeatures* pFeatures);
VkPhysicalDevice is a handle object defined as:
#define VK_DEFINE_HANDLE(object) typedef struct object##_T* object;
VK_DEFINE_HANDLE(VkPhysicalDevice)
This is just a pointer and other imports using IntPtr or SafeHandle wrappers for objects of this shape work.
Managed Side - DLL Import:
Expected DLL Import (but failing):
[DllImport("vulkan-1.dll", EntryPoint = "vkGetPhysicalDeviceFeatures")]
internal static extern void GetPhysicalDeviceFeatures(PhysicalDeviceHandle physicalDevice, ref IntPtr features);
This is similar to other working imports. Note: PhysicalDeviceHandle is derived from SafeHandle should be marshalled to IntPtr, I have other imports with this pattern that work. The above throws an access violation when called.
Platform:
Windows 10 (x64)
Nvidia Driver: 356.43-vkonly (latest)
Update
#V. Kravchenko was correct
There was nothing wrong with the import above. My issue was actually with the vkEnumeratePhysicalDevices call.
First off I had the import wrong, the correct import looks like:
[DllImport("vulkan-1.dll", EntryPoint = "vkEnumeratePhysicalDevices ")]
internal static extern Result EnumeratePhysicalDevices (InstanceHandle instance, ref physicalDeviceCount, IntPtr[] physicalDevices);
Second off, I was actually using the function incorrectly. You need to call vkEnumeratePhysicalDevices twice. The first call gets the count of devices, the second call populates the array of devices.:
IntPtr[] devices = new IntPtr[]();
uint deviceCount = 0;
// populates deviceCount with the number of devices
Vk.EnumeratePhysicalDevices(instanceHandle, ref deviceCount, null);
// populates the devices array with the handle to each device, will only populate up to deviceCount devices
Vk.EnumeratePhysicalDevices(instanceHandle, ref deviceCount, devices);
Note: this is outlined in the description/valid usage section of the function's documentation, I just didn't interpret it correctly on the first read through.
Once I finally had the right handle values from EnumeratePhysicalDevices then my final call to GetPhysicalDeviceFeatures worked as expected. The final import for GetPhysicalDeviceFeatures looks like:
[DllImport("vulkan-1.dll", EntryPoint = "vkGetPhysicalDeviceFeatures")]
internal static extern void GetPhysicalDeviceFeatures(PhysicalDeviceHandle physicalDevice, ref VkPhysicalDeviceFeatures features);
Note: any variable with Handle in the name is a subclass of SafeHandle.
You must IntPtr, which actually does point to a valid object, but not just IntPtr. Access violation means that code in dll is trying to access memory, that your IntPtr points and can't, because your IntPtr doesn't point to a valid object.
Overall, you should use your expected variant, but pass pointer to a valid object.
Working variant is working, because ref IntPtr is actually a pointer to IntPtr, and IntPtr object's location, to which ref IntPtr is pointing, is valid memory.
For example, this is from .NET Framework source file UnsafeNativeMethods.cs:
[DllImport(ExternDll.User32, ExactSpelling=true, CharSet=CharSet.Auto)]
public static extern bool GetWindowRect(HandleRef hWnd,
[In, Out] ref NativeMethods.RECT rect);
and this is from PInvoke.Net:
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool GetWindowRect(HandleRef hwnd, out RECT lpRect);
Which is the correct/best signature for this function? (only one of them has [return: MarshalAs(UnmanagedType.Bool)], or [In, Out] ref, etc.)
I've noticed that in .NET Framework source files many/most signatures have ExactSpelling=true, CharSet=CharSet.Auto, but on PInvoke they don't. Is this required?
They will both get the job done. There's just more than one way to skin a pinvoke cat. Specifically for this example:
ExactSpelling=true is an optimization, it avoids having the pinvoke marshaller looking for the GetWindowRectA and GetWindowRectW versions. They don't exist for this particular API function since it doesn't take a string argument. Seeing an actual difference in run time would be a miracle.
CharSet=CharSet.Auto is always a good idea since the default (Ansi) is so inefficient. It just so happens to not make any difference here since the function doesn't take any string arguments.
[In, Out] is unnecessary because that's the default for a blittable type. An expensive word that means that the pinvoke marshaller can directly pass a pointer to the managed memory, no conversion is required. As efficient as possible. Same idea as CharSet though, being explicit about it helps to create self-documenting code and to remember to deal with the unusual case. Being able to only use [In] or [Out] can be a significant optimization, just not here since it is already optimized. Fwiw, [Out] would have been the correct choice.
out vs ref, same idea as above. Using out is more correct since the API doesn't actually use any passed-in values inside the RECT. It doesn't however make any difference at runtime since the JIT compiler always initializes a struct anyway.
[return: MarshalAs(UnmanagedType.Bool)] is unnecessary, it is the default marshaling for a Windows BOOL. Not sure why pinvoke.net always includes it.
So in a nutshell, neither is perfect but they both will work. Such are the hazards of pinvoke.
This should be simple: I see everywhere people use IntPtr, is there any reason I should use UIntPtr instead?
Doesn't seem like there would be a good reason to. From the docs:
Remarks
...
The IntPtr type is CLS-compliant,
while the UIntPtr type is not. Only
the IntPtr type is used in the common
language runtime. The UIntPtr type is
provided mostly to maintain
architectural symmetry with the IntPtr
type.
Well according to Microsoft UIntPtr is provided mostly for architectural symmetry. Another interesting point is that UIntPtr is not CLS compliant.
On the surface it would seem that IntPtr is the preferred option. However, if you know you will be doing pointer arithmetic then UIntPtr may be a better choice since in the off chance there were some obscure problem dealing with negative values.
There is a big difference.. For example, on a 32-bit application, new UIntPtr(0xC01E0001) results in a pointer at 3223191553, but IntPtr(0xC01E0001) results in a System.OverflowException: "Arithmetic operation resulted in an overflow". That is, because 0xC01E0001 is greater than MaxValue for Int32.
So if one still wants such a pointer, a negative integer needs to be used as internal value for IntPtr, like
unchecked((IntPtr)(int)0xC01E0001)
To answer your question: For values greater than Int32.MaxValue it is easier and somehow cleaner to use UIntPtr. It is probably always the best solution, since pointers are always considered unsigned.