Giving managed control handles to unmanaged code - Access Violation

1
votes

So I have this SDK provided by a third party which is used for viewing streaming video from a remote source. The remote source runs a server provided by the third party that captures and stores video, and I can connect to that server and get video via the SDK. I am referencing the SDK via COM, and basic nongraphical operations like connecting to the server, selecting a video feed etc are all working just fine.

The problem is that the main (only) method for actually showing video to the user using this SDK is to pass an hWnd (as an int) into a method that will then asynchronously paint the video onto the client area of that window. "Window" here, to my knowledge, has the meaning of a GUI window, which in .NET terms would be any WinForms control with a window handle. In my case, I'm using PictureBox controls (one per feed the user wishes to see).

The problem is that I apparently cannot just drop a managed PictureBox control's handle into this SDK method, because when I do so I receive an AccessViolationException from the unmanaged thread. I'm working off of an example program written in VB 6 (which works on my computer against a test server) which does the same thing with a VB PictureBox, and that works just fine, but apparently whatever the SDK is trying to do to our nice safe .NET sandbox objects is not flying with the CLR.

Help? I wish I could give more information or a code sample, but I can't provide anything sanitized enough that it would work in the general case and I can't divulge the SDK being used. I think that what I need is simply to tell .NET that my referenced code should be trusted to do what it wants with the window, OR to somehow move the window to an less-managed memory space outside my program's comfy sandbox.

EDIT: OK, a little progress has been made. I am now verifying that the handle for the control has been created using IsHandleCreated, before giving the handle to the method. However, as Hans Passant said, an IntPtr is not an int. So, how do I fit this square peg in the round hole? I have tried both the ToInt32() function and an explicit cast to (int). Neither works, even when compiling my library for 32-bit architecture. Do I go back to the third party and say their SDK is a POS for not letting me pass a pointer?

1
c#winformsinteropaccess-violation
Should work. A hWnd is not an int, don't try to make this work on a 64-bit operating system. There are otherwise plenty of ways for native code to bomb with an AV without your help. – Hans Passant
You know what? That just might be it; I'm developing in Win7 64-bit, and the interop requires an int, to which I cannot pass the IntPtr Control.Handle directly. – KeithS

1 Answers

5
votes

This should work fine. A Control.Handle for a windows forms control is just a standard HWND from the Windows API. Many DirectX samples use this exact technique.

That being said, make sure this isn't passed into the native code until after the control is created. If you pass the handle during a form's constructor (prior to Load), for example, the Handle will be invalid at that point.