views:

59

answers:

3

Hi

I'm able to run 2 or more WPF windows on different thread. The problem is that now my application in splitted in many windows.

What I really want is have a main window containg a grid in which every cell contains an element managed by a different thread.

Is it possible to create a UIElement/Component managed by a thread that is not the one which manage the parent/ containing window?

or

Is it possible to encapsulate a window that runs on a different thread in some frame/UIElement?

Thanks

A: 

It's not possible in WPF and even if it was it would have been a bad idea:

  1. It's not possible in WPF because WPF element can only be used by the thread that created them, if you add a child element from another thread they wouldn't be able to communicate.

  2. In pure Win32 it is possible - but it joins the two threads message queues so the threads are no longer independent (so even if you find a hack that makes it work with WPF it still doesn't help you)

  3. Any thread that has UI and performs a long running task can hung the entire system - so it's impotent to never perform any long running task in a UI thread - instead run the long task in a background thread

  4. because you have to keep the UI thread responsive -> it should never be busy for a noticeable length of time -> it can handle all your windows because it's not too busy.

Nir
I cannot use background thread because the long running task regards the UI (move and resize hundreds of WPF elements). So I want that during the computation only that component is unresponsive and the menu and toolbar remain responsive and from them I can suspend or stop the long computaiton.So if it is not possible I need some workaround (i.e. syncronize the show/hide/resize event of an empty panel with a window managed by the other thread)
Roberto
@Roberto - Sorry, you have to redesign you app so you don't need to continually move and resize hundreds of WPF elements.
Nir
A: 

Is it possible to use a MediaElement to project a window into a Panel?

Roberto
+1  A: 

"What I really want is have a main window containg a grid in which every cell contains an element managed by a different thread."

One way to go about this would be to create your elements normally in the cell. Create a regular class ViewModel that doesn't touch the UI but runs on it's own thread. This class is the brains behind what you're actually trying to DO with in your cells, not what you're trying to SHOW in your cells. This ViewModel class should implement INotifyPropertyChanged when it's data is has been updated. In your MainWindow.cs file you can set your cell elements' DataContext to these ViewModels. Lastly, in your XAML you can Bind things you're trying to show with the Properties in your ViewModel.

I know I breezed over a lot of details, but it's a starting point. Lots of help to be had around here if you need any.

bufferz
This is what i did before. The problem of this architecture is that WPF thread is blocked by the continious request coming from INotifyPropertyChanged so the requests coming from the user are queued until the INotifyPropertyChanged events are managed
Roberto
Are you saying your properties are updating at a very fast rate? Is it essential that your View updates each and every time the properties change? If not, you could poll your ViewModel in a separate thread every X milleseconds, and only call the UI thread to update the values. Would that make sense in your application?
bufferz