Issue with binding ActionMessage to derived class with overridden virtual method

Feb 22, 2011 at 12:01 AM
Edited Feb 22, 2011 at 12:04 AM

I have an application that is currently using the "workspaces" UI in your documentation.

I have written my own class which inherits from Caliburn's Screen class - MyScreen, which implements an interface that has one method. I implemented the method as virtual, In the ViewModel which inherites from MyScreen I have overridden the method. When my ActionMessage is fired it is going directly to the base class MyScreens implementation of the method instead of the ViewModel's overridden method. Why is this? Originally I had this method implemented ONLY in the derived ViewModel and it was firing correctly... I assume it has to do with the footnote in the documentation: "2. Actually, if no handler is found, before an exception is thrown, the framework will check the current DataContext to see if it has the requested method. This seamed like a reasonable fallback behavior." I'm sensing your framework is casting it to the type of MyScreen so I must be missing something very small to get it pointed to the correct place.

Other notes: the action is coming from a listbox on my Shell which has the following properties: 

 

 

<ListBox DataContext="{Binding ActiveItem}" ItemsSource="{Binding Path=Filters}" SelectedIndex="{Binding FilterNumber, Mode=TwoWay}"  Style="{StaticResource FilterNavigationMenuStyle}">

 

ActiveItem being the screen conductors ActiveItem(Which should be my ViewModel). Here is also my event trigger:

 

 

<i:EventTrigger EventName="SelectionChanged">
<cal:ActionMessage MethodName="FilterChanging">
            				<cal:Parameter Value="$eventArgs"/>
            			</cal:ActionMessage>
            		</i:EventTrigger>
Coordinator
Feb 22, 2011 at 12:03 AM

I'm not sure why this would happen. Can you create a simple solution that reproduces the problem and email it to me? robertheisenberg at hotmail dot com

Feb 22, 2011 at 12:04 AM

Does this edit help?:

Originally I had this method implemented ONLY in the derived ViewModel and it was firing correctly... I assume it has to do with the footnote in the documentation: "2. Actually, if no handler is found, before an exception is thrown, the framework will check the current DataContext to see if it has the requested method. This seamed like a reasonable fallback behavior." I'm sensing your framework is casting it to the type of MyScreen so I must be missing something very small to get it pointed to the correct place.