Combined CCR with WPF

Question

Hi,

I was wonder if anyone try to combined CCR and WPF application to accomplish async UI.

I'm not sure it's the best but I don't see any better alternative.

What do you think?

Answer 1

There is a WpfServicePort that allows to interact with the IU in the single thread context. You should take a look to this sample : http://msdn.microsoft.com/en-us/library/cc998523.aspx

In my company, we have used WPF and CCR without any problems

Regards,
Vincent

---

http://www.simplysim.net/

Answer 2

Hi, Thank you for the reply. The sample you point me to create WPF UI from within DSS service. What I'm looking for is way to have WPF application and use CCR (I think without DSS) as execution engine. Think that when ever a button is clicked, window open I'll use CCR to execute the task and have a port, which now to return messages back to the UI thread, which will handle UI updates. I'm not sure how to implement such thing since some of the operation can be executed in another thread, while other must execute on the main thread like accessing UI elements, modifing ObservableCollection (or a like) and UI navigation. What do you think? Thank you, Ido.

Answer 3

The sample I have given is for DSS but could be easly adapted to CCR :

var dispatcher = new Dispatcher();
var queue = new DispatcherQueue("Dispatcher Queue", dispatcher);

WpfServicePort wpfPort = WpfAdapter.Create(queue);

wpfPort.RunWindow (...);
wpfPort.Invoke (...);

When you have created the WPF port, you could run and modify the UI with RunWindow and Invoke method. With this adapter, you are sure that the same thread will be use to create and modify the UI (to follow WPF single thread requirement)

 

---

http://www.simplysim.net/

Answer 4

Hi,

Thanks for the code sample.

This is just the technical stuff of how to pass message from any context back to wpf.

My question is more general - what kind of application model can/should we use when integrating Wpf with Ccr ?

I'm currently developing my WPF application with MVVM model, and I think ccr can be used in the ViewModel layer quite nice.

Ido

Answer 5

First some technical concerns :

MVVM model in WPF usually uses the data binding to link the view and the view model together. Supposing that your view model class implements the INotityPropertyChanged, the PropertyChanged, I guess, must be raised only by the thread that has created the window (single thread UI requirement). So when you want to raise this event, you must use a special Dispatcher queue, linked to a single thread dispatcher, or the CCR Wpf adapter.

Then about model :
As you say CCR could be used in the view model. The commands exposed by the view model could have a associated port with an attached receiver that will schedule the handler when a item will be posted on the port. You should also think about adding "response ports" to your command (like DSS operation) to refresh the UI with the command response.
Refreshing the UI could be done by a set of receiver, created by the view model on response ports or "event" port of the model layer that just updates the state of the view model, and then, raises the PropertyChanged event (with the single thread requirement) to update the UI. To manage these receivers, I think that a Interleave for each view model object is a good idea, since you have to manage concurrency on view model state modifications.

Regards,
Vincent

---

http://www.simplysim.net/

Answer 6

Hi,

I'm glad to see someone has the answers :)

I'll do some sample code and get back with more questions.

I really excited about this, I think it can help make much better software.

Ido.

Answer 7

I thin a big concern with UI and CCR is to rethink the "look and feel" with asynchronous system. Usually, when you click on a button, a menu, a picture, an action is directly executed and 'freeze' the interface (for short time). For long action, the asynchronous pattern is generally used (but with the concurrency and coordination classic problems). If you UI is "full CCR", all you command will be "asynchronous" (you will just schedule work to the dispatcher), so you have to think what to do in the UI while waiting the job to be done. For example, if you don't want to have a button clicked multiple times while the associated command is executing you have to disable it until you receive the command response (maybe by playing with the command CanExecute property).
You may also have to review UI "pattern" that will not be adapted to an asynchronous logic layer.

---

http://www.simplysim.net/

Answer 8

Thank you. You express the problem well, I'll just add one thing and then I hope we can try and find a solution.

In my application everything is synchronous and by everything I mean the request of data, update of data (in my case I request and update data from REST web service but it doesn't really matter).

If I just put CCR in the UI layer then button click will schedule work to the dispatcher but the work will actually be "whole unit of execution" it will use a whole thread from beginning to end even when it will wait for I/O. I'll just "off-load" the work from the UI thread to CCR thread.

If I really want to take advantage of CCR I have to change the way I interact with the data request and update and make it truly asynchronous.

Do you agree?

Answer 9

Yes, the business and data layers should be in CCR to take advantage of multi thread (especially on multi core CPU). The CCR just makes the multi thread programming easier, you could do the same with the .net thread api (but it will be much more complicated and with the 'dispatcher' system, CCR uses the threads in an optimal way).

---

http://www.simplysim.net/

Answer 10

I see. My question now is what is the model?

Every method that used to be sync is not turn into a method that return void and accept Port or PortSet (so it can indicate failures too) and post the result into that port?

How do you manage so much ports?

Thank you,

Ido.

Answer 11

Hi,

I just like to post a short update.

I've implement a data layer with CCR (all the way down to sending web request using CCR).

The good side is that it really works faster, the work is much more unified in the sense that almost everything is message post to port (some internal stuff are IEnumerator<ITask> methods that get schedule using yield return). The UI is free and much more responsive.

 

The bad side is that it's still hard to debug CCR code since tools like stack trace and structured exception take a different form and some tools are still missing (yet they are possible to be develop).

 

As Vincent said it's not whole new world for UI design since I have to this what to do while operation is been processed, what the user can still do and who to make it clear to the user what is going on right now in the application.

 

One thing that still unclear to me is how to marshal handlers back to the UI thread in unified way.

If you have an idea please post it here http://social.msdn.microsoft.com/Forums/en-US/roboticsccr/thread/29d3cb32-ebe8-4e7d-988c-74e051c1fdfd (thread I open about that specific question).

 

Thank you very much CCR team for great work,

Ido

Answer 12

Wouldn't Commands in WPF be the thing to use for this?
(Which might be stating the obvious considering that the MVVM design pattern is used ... I am myself just starting to learn how to combine CCR and WPF using MVVM. And just to get the "icing on the cake" I'm also throwing in MEF (Managed Extensibility Framework) for the modularity.)

 

///JmD

 

Answer 13

Hi JmD,

You are right, Commands are doing exactly that, but command are only part of the solution.

When everything is concurrent we have to make sure the UI is aware of it because let's face it, most UI take for granted that while an operation (command or anything else) is running, nothing else is running and nothing else can be done.

For example, my whole data access layer is based on CCR. When I actually commit my changes to the back-end server nothing should be changed in the local data (at least the way I see it) and I still don't have a good way of show that in the UI. I don't want to just disable everything while committing because we will be back at square one which is nothing move while committing. I want to still let the user browse around while is commit in the background.

 

Also there is the thread affinity issue. I know the CCR team have the WPF adapter but it's not really helpful in most cases I run into.

 

Another (general, not UI specific) issue is that the CCR is a library, not a language. I am still using C# to build the application. It is possible but dangers to mix CCR and OO together since the one place you will access a "state" member without going throw Interleave you loose the CCR protection. It's like accessing a member in multithreaded OO application without using some kind of lock.

The solution is off course pure CCR application, but WPF is not pure CCR so there has to be a bridge.

 

I'll be glad to share me experience about using the CCR. I love it and hope Microsoft will improve it and continue with it.

 

Ido

Answer 14

Hi there Ido!

Now I have been developing an application for a while where I combine WPF, CCR and MEF. I started using the MVVM pattern, but since I'm making a plugin-based app I ended up having three classes for every plugin which resulted in a lot of files and classes. So I re-wrote the app using a simplified "pattern" where I only have a Model and a View for every plugin.

The Models of the plugins in the app sends information to each other in forms of CCR messages. The View of a plugin uses databinding to the Model. When a plugin recieves a CCR message (in the Model) the View gets updated through the data binding. This has worked (oddly enough) without me using the WpfServicePort. Textboxes, progression bars, sliders etc get updated without any problem. But when I tried to update the color of an UI element on a plugin View I got the "this belongs to another thread"-error.

My app consists of a framework and a framework View which is a single WPF window. In this framework plugins get loaded (through MEF) at runtime. Each plugin is made of a Model class and a View class. The View class is a class inheriting from UserControl. When a plugin gets added to the framework, the View of the plugin gets added to the children of a canvas in the framework window.

My current solution to the  "this belongs to another thread"-error is to let the framework window be created by a WpfServicePort (using the WpfPort.RunWindow() method). This at least removes the thread-related error, but the data binding (from a Color value on the plugin Model to a element Color on the plugin View) doesn't seem to work very well, and the UI gets very sluggish.

I'm currently looking into how I should use the WpfPort.Invoke() to update the View of a plugin. The WpfPort is a member of the framework Model and the WpfPort.Invoke() will invoke some method in the framework View class I guess, since that is the Window that got created by the WpfPort.

I just find it strange that I had no problems updating textboxes, progressbars etc on the Views of my plugins through data binding to the corresponding Models, but I get the thread-related error when I try to update the color of some element on the plugin View.

Well, there you have some rantings from me on my current development status. Feel free to comment on this if you like.

///JmD

---

///JmD

Answer 15

Hi JmD,

 

As I wrote here in the past I'm been trying, and accomplish, to combine CCR with WPF. It works for me mostly in the part of loading data from a remote web-server and keep the UI active and make the loading as concurrent as possible.

I am also trying to use CCR within WPF but this is little harder. The fact is we still need to obey to WPF rules of thread affinity. The fact that Microsoft allow us to raise PropertyChanged even from background thread is nice-to-have but not to count on since it only works for simple properties but surly not for collections.

I don't think using WpfPort is the answer because WpfPort was built in CCR centric in mind while what we are doing is WPF centric in mind. The only advantage of using WpfPort is that it is a port and it allow us to synchronize with it like we do with any other CCR port.

I'll try to bring here some code I use today and see if we can get together to good practice of WPF and CCR.

 

I really hope the CCR team will help us figure this one out.

 

Thank you,

Ido

Answer 16

Hello Ido!

The WpfServicePort did solve my problem. I think you're right about this solution beeing CCR centric, and that is ok with me. Since I'm mostly making quite graphics intensive apps with a lot of information flying around I feel the CCR is a good model for me. WPF is just another GUI technique to me. The WPF-centric programming model doesn't work very well for my application. I have many visuals that are to be updated in real time, and so far I've been basing the Views of my plugins on the UserControl. This makes the GUI sluggish when there are many visible plugins with realtime updating. Since the GUI response and the overall feel and visual impact is very important to me, I'll start looking into a more lightweight solution for the Views of my plugins.

The CCR model is very appealing to me and I tend to base parts of my solution around it. The "code-less" approach of WPF (using XAML) is a nice thing, but for me it is more important with a high performing GUI than a designer friendly framework for my app. I think my solution will be more CCR centric rather than WPF centric in the end.

What I do like about WPF (for my specific needs) is that it is vector based (resolution independence) and that it utilizes the GPU (speed). The parts making it designer friendly, like XAML and data binding, are nice but not very important to me, and if those parts degrade performance I have must get rid of them. It seems the overhead of UserControl is what is becoming a problem in my application.

 I'll be looking into more ways to combine CCR and WPF but I will do it from the CCR point of view rather than from WPF. My main focus will be speed and real time response.

///JmD

---

///JmD

Answer 17

Hi,

I think you should have a look at this blog post about priority binding and this msdn page which explain the technical side of it.

I don't think you should cut Binding out, there are ways to make Binding work fast and still leave good separation between view and model. Also there are ways to deal with background-update model if it is done but CCR or plain old threads.

The good thing about CCR is that is make synchronizing between tasks very easy.

 

If you have the time to make some sample application which demo the problem maybe we can help you with it and learn from it.

 

Ido