[.net] [SOLVED] Win32 DLL hosting WPF content

Started by
2 comments, last by mutex 16 years ago
hey all, I'm having trouble coaxing a win32 dll in to drawing WPF content. The problem lies in making my dll (or at least wpf rendering part of the dll) single threaded. Normally if I want to make a Win32 window draw WPF content I would just throw the [System::STAThreadAttribute] in front of the main entrance point for the app to make the entire application single threaded. My problem is that my dll only has two functions exported, init and shutdown. Init calls the Init of a wrapper class for my WPF content which is suppose to create the window and draw the content. The problem is that somewhere along the line I am suppose to be setting the STA attribute on my thread and I'm not really sure where since all the WPF interp documentation always just talks about placing [System::STAThreadAttribute] in front of the entrance point. In short, My application's pipeline is the following, I need to know where/how to set the thread to be STA. -- native c++ app -- my wpf interop dll (wpf wrapper class w/ init function) -- wpf content [Edited by - maxdub on April 22, 2008 7:02:37 PM]
.max
Advertisement
I'm not familiar with this area, but have you tried CoInitializeEx(NULL, COINIT_MULTITHREADED) as part of initializing the native thread that calls the WPF stuff?

solved it on my own... you were close Mutex but you can't change a thread's concurrency model once its already been set and since i was trying to use the main thread, it wasn't working for me.

what i ended up doing was very close to what you were saying but i did it through managed code. I created a managed worker thread that ran on STA and then asked that thread to draw all the content.

more info:
http://msdn2.microsoft.com/en-us/library/system.threading.thread.aspx
.max
Doh, that was my initial response but I assumed you didn't want to create another managed thread given that your native app is calling managed code.

This topic is closed to new replies.

Advertisement