Need C Sharp win32, PInvoke API

Hi All,

Long time listener, first time caller. Does anyone know of a good interop library for the Win32API?

I found pinvok.net which is OK. (FWIW I got the addin to work with MSVS 2010 by following the instructions here: http://www.red-gate.com/supportcenter/GeneralContent.aspx?c=knowledgebase\PInvoke\KB200711000198.htm and using 10.0 instead of 9.0)

...and the Windows API Code Pack 1.1 from MSDN seems not to have the basic Win32 stuff from user32.dll or am I missing something?

More specifics... I am trying to take an external window and make it a child of a control in my managed System.Windows.Form (embedded GUI in a panel or tab of my main form). Researching here and on google it seems like Win32/user32.dll is the way to go. My application is a framework that launches 3rd party GUIs (dlls and exes). The 3rd party code/forms are all unmanaged (mostly MSVC) code. These unmanaged forms are launched from within my process hierarchy. My preference would be to stay in .NET if is possible.

The best interop library available is the .NET Framework. User32.dll is wrapped very well by Windows Forms.

The Windows API code pack concentrates on wrapping API additions made in Vista and Win7. Those were not additions to user32, mostly shell stuff.

You'll probably get a better answer if you can be specific about exactly what user32 APIs you want to use.

After seeing edit: what you are trying to do is explicitly forbidden by the Win32 SDK documentation. The parent of a window must belong to the same process. There are however some appcompat hacks in Windows, designed to support Windows 3.x programs where this restriction did not exist. Because it didn't support threading.

You can try, but beware you'll void the warranty. P/Invoke SetParent(). Visit pinvoke.net for the declaration you'll need.

The trouble with some of the wrappers around the Win32 API is that they aren't well exposed. Directory.GetFiles is terribad. Why does it return an array when the underlying Win32 API allows streaming? It took until version 4 to fix that ><

Bear Monkey 2010-09-23 18:36:22

@Bear: Yeah, there are a couple of places where life would have been better had the API been written later (Directory.GetFiles predates generics, so IEnumerable<string> wasn't an option at the time...). However, I'd still argue that it's a rare case where it's better to wrap your own method vs. using the framework, for various reasons, including maintainability by others, ease of use, development time, etc.

Reed Copsey 2010-09-23 18:38:46

@Bear: (And Directory.GetFiles() still returns string[] in .NET 4 - though DirectoryInfo.EnumerateFiles works, and is .NET 3.5: http://msdn.microsoft.com/en-us/library/dd413232.aspx)

Reed Copsey 2010-09-23 18:40:43

@Reed Yes you right i didnt mean they changed GetFiles. Sorry I was thinking of EnumerateFiles method when i said they had fixed it.

Bear Monkey 2010-09-23 18:47:06

@Reed. Actually according to your link DirectoryInfo.EnumerateFiles is supported only in version 4.

Bear Monkey 2010-09-23 18:51:59

@Bear: That was the .NET 4 link - 3.5 is here: http://msdn.microsoft.com/en-us/library/dd413232(VS.90).aspx

Reed Copsey 2010-09-23 18:59:05

@Reed i must be going mad because Version Info says Supported in: 4 only. Also im using .Net 3.5 at work and Visual studio says DirectoryInfo.EnumerateFiles method doesn't exist. Am i missing a reference?

Bear Monkey 2010-09-23 19:05:19

@Bear: I think it's a doc. bug. I had thought it was 4.0 too - but then I saw it listed on the 3.5 page (which that second page references)... sorry about the confusion. I'll post it as a bug on connect, though ;)

Reed Copsey 2010-09-23 19:07:30

@Reed. No problem. Yes its a doc bug with msdn Classic View. It says 3.5 at top but 4.0 at botton. Try changing view style to LightWeight which I was using its much nicer.

Bear Monkey 2010-09-23 19:10:34

Sysinternals procexp.exe shows the process of the child-window-to-be as a node under my main process... Does that help at all?

dFlat 2010-09-23 22:18:45

It doesn't. Parent-child process relationships have very few practical advantages in Windows. The only angles there are is that a *console application* can inherit a parent console by default. And the notion of "jobs", started by CreateJobObject, that allows killing processes as a group. Thoroughly screwed up in Vista+. Big difference between Windows and *nix btw. No fork() in Windows.

Hans Passant 2010-09-23 22:40:53

ansaurus

tags:

views:

answers:

Need C Sharp win32, PInvoke API

related questions