Interaction Request + Windows Forms

Topics: Prism v4 - WPF 4
Mar 18, 2011 at 12:12 PM


I have a view which contains a Windows Forms control (hosted by WindowsFormsHost). The winforms control is added to the page programmatically. Now I have to call a method of the winforms control from the ViewModel. I tried to do that using Interaction Request:


            <prism:InteractionRequestTrigger SourceObject="{Binding SaveDocumentInteractionRequest}">
                <a:SaveDocumentAction />

        <wfi:WindowsFormsHost HorizontalAlignment="Left" VerticalAlignment="Top" Margin="0" Padding="0" Grid.Row="1" x:Name="wfh" AllowDrop="true">

In The SaveDocumentAction (custom action implementation) I then have to call the method of the winform control instance. But therefore I need the view instance inside the action class. How to solve that? Is that generally the right approach for this scenario?
Or would it be better to simply provide an event at the ViewModel to notify the view about when to call the winforms method? The Interaction Request approach seems a bit circular, since it isn't really a UI topic  / user interaction (just want to notify the view to call a method of the winforms control).. Any guess? 

Regards, Andreas

Mar 18, 2011 at 6:09 PM

Hi Andreas,

From the Advanced MVVM Scenarios chapter fo the Prism MSDN documentation, interaction requests are useful "to allow the view model to make interaction requests directly to the view itself via an interaction request object coupled with a behavior in the view. ia events. The view subscribes to these events to initiate the user experience portion of the interaction. The view will typically encapsulate the user experience of the interaction in a behavior that is data-bound to the interaction request object provided by the view model (...)".

Since the behaviors mentioned in the description above reside in the view, it shouldn't be wrong to include the method call to the winform contrl instance. From the documentation, "Because the interaction request object represents a logical interaction, the exact user experience for the interaction is defined in the view. Behaviors are often used to encapsulate the user experience for an interaction; this allows the UI designer to choose an appropriate behavior and to bind it to the interaction request object on the view model. The view must be set up to detect an interaction request event, and then to present the appropriate visual display for the request. The Microsoft Expression Blend Behaviors Framework supports the concept of triggers and actions. Triggers are used to initiate actions whenever a specific event is raised."

Take into account that interaction requests are useful to separate the logical interaction (in the View Model) from the exact user experience for that interaction. If you don't need to do so (for example, because you need to call a method in the WinForms control that does not necessarily have to do with the user experience), you shouldn't benefit from using Interaction Requests.

I hope you find this helpful.

Guido Leandro Maliandi

Mar 21, 2011 at 9:49 AM

Hi Guido,

thanks for your hints. I already read the documentation about Interaction Requests, and my guess is also thats not really the right thing for my scenario. But what's my alternative? How to call a method of a control which resides inside the view from the ViewModel?

The only thing I could imagine would be to raise an event in the ViewModel and attach the view to this event to get notified, but is that MVVM-like? Would it be more appropriate to use the Event Aggregator for that?? Is it intended in PRISM to publish an event in a ViewModel and subscribe to this event in a View?? Should I do that?


Best Regards

Mar 21, 2011 at 7:41 PM

Hi Andreas,

A possible workaround to achieve your requirement would be to use a service, shared between your View and your ViewModel, to communicate those values. You can read more about shared services in the following chapter from the Prism MSDN documentation:

Chapter 9: Communicating Between Loosely Coupled Components

I hope you find this helpful.

Guido Leandro Maliandi

Mar 22, 2011 at 11:59 AM

Hi Guido,

Thanks, but I don't understand:

Why would you prefer a service instead of Event Aggregation?

Best Regards,


Mar 22, 2011 at 2:50 PM


The Event Aggregator is usually used to achieve communication between components located in different assemblies. As your requirement for communication is between a View and a ViewModel located in the same assembly, it shouldn't be necessary, although you could use it if you prefer to.

I hope you find this helpful.

Guido Leandro Maliandi

Aug 22, 2011 at 1:58 PM


I keep finding "help" to setting up Shared Services that simple points to "Chapter 9." It's useless. I clicked the "Feedback" link on the MSDN page for "Chapter 9," and left this feedback.

  1. For what I am trying to learn, Shared Services and Event Aggregator, the information in Chapter 9 is almost non-existent.
  2. The Stock Trader RI example code may be complete, but it is way too complex. I'm spending way to much time fishing through it to figure out how it works.
  3. The examples in Chapter 9 refer to non-existent code in the latest Stock Trader RI example.
    Perform a full Solution search on "this.eventAggregator.GetEvent<TickerSymbolSelectedEvent>().Subscribe"
    Nothing is returned.
    The latter text is supposed to be in the file "MarketModule.cs." But in that actual file, you find this in the comments:
    "This module is intentionally left empty because views, services, and other types are discovered through declarative attributes. View registration for this module is done through the ViewExportAttribute."

To summarize, Chapter 9 does not cover the most difficult subject, is out of date, and refers to code that does not exist in a too-complex example.

Our application requirements include shared code for both Silverlight and WPF, and must be built with MVVM architecture. A typical application in our software suite may have 8 modules, 10 ViewModels, and 10 Models. We need the ViewModels to communicate with each other such common information as the user's credentials and the individual product or customer being maintained, so they all stay in sync with each other. So I have to echo "acenet's" comment when it comes to using the Stock Trader RI example along with the MSDN documentation: "I don't understand." That should be sad to hear from a Senior .NET developer (since .NET 1.0 beta 1) who already has long experience in WPF and MVVM. I'm just new to Prism. It shouldn't be this hard to learn.

Aug 23, 2011 at 5:52 PM


As of the release of Prism v4, the StockTrader Reference Implementation has been modified to use MEF; therefore, certain changes were made so that it makes better use of the capabilities MEF provides. In the case of the MarketModule, a placeholder was left because there was no need to perform any action on its Initialize method; this is because, unlike Unity, MEF uses declarative attributes to export types, which are defined in the exported classes themselves, instead of having to register them in the container in the module's Initialize method.

On Chapter 9, the example is based on the StockTrader Reference Implementation from Prism v2.x, which is the previous version of Prism. As this is outdated and might cause confusion, we've created a work item in the issue tracker, so that the produc team takes that into consideration.

Finally, you might also find the Prism Training Kit useful for your concerns, as an additional piece of guidance on how to use Prism to fulfill your requirements.

If you have further concerns about Prism which aren't clearly explained in the documentation, you could create a separate thread in which we can discuss them, so that you don't experience difficulties when using Prism to develop your application.

I hope you find this helpful.

Guido Leandro Maliandi

Aug 23, 2011 at 6:16 PM
Edited Aug 23, 2011 at 6:17 PM


You might also find the following blog post useful, which might be useful to understand why the MarketModule is empty in the StockTrader Reference Implementation in Prism v4:

Prism modularity differences when using MEF

I hope you find this helpful.

Guido Leandro Maliandi

Oct 18, 2011 at 7:38 PM


As Nelly Delgado mentions in the work item I created in response to your comments, the documentation has been updated to address these problems.


Guido Leandro Maliandi