Ramifications of calling unmanaged code to customize controls?

J

Just Gooey

In order to provide some functionality to .NET forms and controls that
were available in MFC, I've noticed several examples where unmanaged
DLL entry points are referenced and then called.

For example, I can add:
[DllImport("User32.dll")]
public extern static bool SetWindowPos(
IntPtr hWnd, // handle to window
Int32 hWndInsertAfter, // placement-order handle
Int32 X, // horizontal position
Int32 Y, // vertical position
Int32 cx, // width
Int32 cy, // height
Int32 uFlags); // window-positioning options

private const int SW_SHOWNOACTIVATE = 4 ;

[DllImport("user32.dll",SetLastError=true,
CharSet=CharSet.Unicode, ExactSpelling=true,
CallingConvention=CallingConvention.StdCall)]
public extern static int ShowWindow(IntPtr handle, int showCommand) ;

Then in my class I am able to call SetWindowPos() to change position
and call show window without activating the window or control. The
Show() method in forms does not take an activation flag.

I am curious as to the performance impact, or other possible
ramifications, of doing this. Any comments?
 
D

Dmitriy Lapshin [C# / .NET MVP]

Hi,

The only problems with the code given I can envisage are:

1. Lack of permissions to make P/Invoke calls will cause your program to
fail. This is rare case for desktop applications but the most security-aware
users may experience problems if they tighten permissions on their machines.

2. Windows versions compatibility. Ensure the P/Invoke calls you make are
supported by all the flavours of Windows you expect your program to run on.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top