Allow a DLL to control a portion of the screen

[Virchanza]

In my day job, there is a team of people who maintain a very big desktop PC program written in C#.

I'm the guy who programs the microcontrollers in C++.

I am very familiar with the Win32 API from when I programmed in Visual Basic circa 1998 - 2002, and I've written a few C programs too with a message loop.

The idea being floated around my company at the moment is that I will write a dynamic shared library in C++ and produce a DLL file to give to the C# guys. The C# guys will then load my DLL file into their program, and they will call a function inside my DLL file and give it a handle to a window (i.e. HWND) on the screen.

So my DLL will have access to a piece of real estate on the screen. I will create buttons and text boxes using the C functions in the Win32/Win64 API, i.e. the likes of CreateWindowExW.
Normally a Win32/Win64 program written in C has a message loop where 'GetMessage' is called continuously, but I won't have access to the message loop as it's probably buried somewhere inside the CLR (Common Language Runtime). So this means that I can't directly intercept the BN_CLICKED messages sent to the buttons I've created on screen.

What I can do though is subclass each of the windows I create, and specify a custom WndProc for each of them, and so then the message loop inside the CLR will call DispatchMessage which will invoke my custom WndProc. So this means that my DLL will be able to react to the button clicks.

Do you reckon I'll be able to get this to work?

 

[Skydiver]

Yes, as long as the code written in C# is using WinForms as it's UI framework. If they are using WPF, WinUI, etc. giving you a window handle for your code to render into is going to be a lot more difficult because there won't be any child windows for you to use as your parent window.

 

[Virchanza]

Yes, as long as the code written in C# is using WinForms as it's UI framework. If they are using WPF, WinUI, etc. giving you a window handle for your code to render into is going to be a lot more difficult because there won't be any child windows for you to use as your parent window.

If they use WPF, WinUI, etc., then they could give me three things:
(1) The hWnd of the main window
(2) The top-left corner pixel of my real estate in the main window
(3) The width of my real estate
(4) The height of my real estate

That would be all I need, right?

 

[Virchanza]

I've asked the C# guys just now, and they say it's WPF.

 

[Skydiver]

WPF uses DirectDraw. You'll need to somehow interact with how WPF uses DirectDraw to render its screen. Or you could try floating your own window on top of your designated area. You'll need to be notified of window state changes and resizes.

 

[Skydiver]

Alternatively, if you know how to write an ActiveX control, your code could be an ActiveX control:

Host an ActiveX control in WPF

Learn how to host the Microsoft Windows Media Player as a control on a Windows Presentation Foundation page.

learn.microsoft.com

 

[Skydiver]

Or even better, something closer to what you want to do:

Host a Win32 control in WPF

Learn how Windows Presentation Foundation provides a straightforward mechanism for hosting a Win32 window, on a WPF page.

learn.microsoft.com

 

[Virchanza]

I'm ready to start writing the code for my DLL, but the C# guys are telling me that the C# program has a fancy looking skin -- the buttons are slightly oval in shape, and navy in colour. So if I use the Win32 API function CreateWindowExW to make a button then it will just look like a normal rectangular grey button.
Is there any way at all that my DLL could create buttons and text boxes that have the same skin as the WPF program? I was thinking I could use the program "Spy++" on the WPF program to select a button to get its "window class" and also the address of its WndProc. Then maybe if I create a new window with the same class and WndProc, I might get a button with a skin on it..... ? maybe.............?

 

[Skydiver]

No. You will have to do your own owner drawn controls and write code to emulate the WPF UI Elements.

No. You cannot just run Spy++ on WPF because all of WPF is just a single drawing surface used by DirectDraw. It's just like your can't just use Spy++ on your favorite DirectX games and get window handles of the various widgets in the games -- the entire game is a single DirectX drawing surface.

I highly recommend that you just expose a set of APIs from your DLL that does all the logic and other work, and let the C# folks write the UI and the glue code that will call your APIs.

 

[Skydiver]

Another alternative is to write in Managed C++ (aka C++/CLI). You'll be writing code in C++, but you'll be exposing objects/interfaces that look like regular C# objects to the C# programmers.