Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 824
  • Last Modified:

how to call code in C++ library that needs to keep a running thread from my WPF app

I have an unmanaged legacy C++ app.
I gave up on trying to load a stylized WPF window from a newly-managed C++/CLR build of the app,
and instead I tried creating a new C# app using the stylized WPF windows (by stylized I mean I'm using a 3rd party dll that contains xaml/wpf window styles).
in other words, I'm trying to recreated the UI part in a new C# app using WPF, but don't want to migrate all my legacy non-UI code.

The problem is I want to load my old C++ code from this new C# app in such a way that the C++ code can kick off a thread and keep it running in order to do all sorts of fancy stuff.

if I just call my main exported function, then it won't return control to my C# app until the thread exits.
Do I need to do a LoadLibrary() to make sure the dll stays in memory?
I want the C++ dll to kick off a thread and stay in memory while my C# WPF app displays a window (and the 2 should talk to each other of course) - not be sequential!

What's the right way to accomplish what I want to do?

e.g.
    public partial class App : Application
    {
            [DllImport("Client_DLL.dll", SetLastError = false)]
            static extern int MyDllMain();

            //IntPtr hDll = LoadLibrary("Client_DLL.dll");

            int nRet = MyDllMain();
}
0
povjetset
Asked:
povjetset
  • 6
  • 2
1 Solution
 
XMarshall10Commented:
I think only explicit linking (LoadLibrary) and then after your work is done, call FreeLibrary so that windows can Unload your dll.

In between windows should not unload the dll from memory, as internally windows maintains a reference count or counter indicating how many clients are using this dll at any point of time.

-XM
0
 
povjetsetAuthor Commented:
thanks, but as I mentioned, I can successfully call a function in my c++ dll
The problem is that if that function starts a thread, then the function does not return (back to the C# code that PInvoked it) until the thread exits! (which of course defeats my purpose of wanting that thread to keep running while my WPF C# app runs the uI)

I only added the LoadLibrary because I thought maybe the dll was getting unloaded after the function returned, killing the thread, but that's not the case. The LoadLibrary seems irrelevant.

Can I start a thread in my WPF app and have it call pinvoke that function (which wouldn't need a thread on its side)?
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
povjetsetAuthor Commented:
Update: ok, so I create a thread and then pinvoke my dll function from there, seems to work, i.e. my thread in the dll is running, and my main WPF thread is controlling my new UI. (not sure if a BackgroundWorker would have been better than a regular Thread due to the cross-thread dispatching issue)

So now the real issue:
- how does my C++/CLR code send commands to the C# app, i.e. to update the UI window, since it didn't create the WPF window and it's running in a different thread?
The sample code I see everywhere for hosting a WPF control inside a C++/CLR app doesn't seem to apply...
My Window class is defined in C#, so even if I passed a reference to it via a pinvoked call to the dll, and the dll stores it in a managed class, how do I call a member function of that class (or post a message to it, if that's possible)? As I mentioned, the window was defined in C#, not C++.
How do I attach an event handler to the C# class reference in my C++/CLR code?

FYI I can successfully I can handle the reverse by calling a new C++ dll entry point that takes a UINT cmd, which then posts the command to the internal hidden window, which gets handled in the message loop that is running inside the dll (just like the code used to do).
0
 
povjetsetAuthor Commented:
I think I have a workable solution:

When the C# window is created, use a WindowInteropHelper to get the hWnd and pass that in to my dll

            WindowInteropHelper wih = new WindowInteropHelper(mywindow);
            IntPtr hWnd = wih.Handle;
            MyDllFun(hWnd);

Then my dll can simply PostMessage (with user-defined messages) to that hWnd as neeeded

Back in C#, process the messages by doing an AddHook on the HwndSource (from http://www.steverands.com/2009/03/19/custom-wndproc-wpf-apps/)

    public partial class MainWindow : Window
    {
        ...

        protected override void OnSourceInitialized(EventArgs e)
        {
            base.OnSourceInitialized(e);
            HwndSource source = PresentationSource.FromVisual(this) as HwndSource;
            source.AddHook(WndProc);
        }

        IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
        {
            // Handle messages...
            if (msg == 666)
            {
                MessageBox.Show("Received msg 666");
            }
   
            return IntPtr.Zero;
        }
   }

amazingly, this actually worked for me!

Is there any reason to be concerned that this won't work properly?
0
 
povjetsetAuthor Commented:
well, there is still one issue: how do I send a string in those messages? Can I use GlobalAddAtom/GlobalGetAtomName (in both directions, i.e. posted in a message either from C++ to C# or from C# to C++ although in the C# to C++ case, I can marshal the string and pass it in the pinvoked function, which if necessary can then create an atom to postmessage internally)

so what about sending a string from the C++ code to the C# WPF window?  (yes, I know the UI text should really reside with the UI code, but I have resource dll's and legacy code already building the required string to show in the new UI)

note that currently I didn't need to recompile my C++ dll with /clr since I'm only using PostMessage

0
 
povjetsetAuthor Commented:
my other workaround for this string issue is to save the string (or regenerate it based on an id) and pass the id in the postmessage, then have C# call a MyDllGetString() api with the id
not great but works for a majority of my messages
0
 
XMarshall10Commented:
Since you already have the window handle, I guess you can send your string data to that window by packing your data inside wParam or lParam parameters, and process it accordingly in the receiving window. This approach is very common and may be a bit simpler.

-XM
0
 
povjetsetAuthor Commented:
you can't pass a string in a windows message, and a GlobalAtom is limited to just under 256 chars
But passing/getting a string between C# and C++ is easy.

in short, I guess my solution is like doing a COM control without using COM (and with making data exchange a a little less convenient). Given my limited interactions, that seems ok for now, but if things get hairier, I'll probably have to make the C++ code a full-fledged COM control
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now