Current filter:
                                You should refresh the page.
                                • Magnus Haggren 05.16.2011

                                  Do you have an ETA for this suggestion?

                                • Hi Magnus,

                                  I am afraid at the moment we cannot tell whether this functionality will be implemented, and when this will be done. We already tried to make the BarItem a descendant of the FrameworkElement class, but run into a number of serious problems we have not yet found a way to address to.

                                  However, we have found an alternative solution. Instead of working with the Window's Triggers, you may consider using EventTriggers from the System.Windows.Interactivity assembly, which seem to provide a similar functionality and also provide a built-in InvokeCommandAction, allowing you to invoke a command from your ViewModel with ease. Even though there is no built-in BeginStoryBoard action in this library, you can overcome this limitation by writing a System.Windows.Interactivity.TriggerAction descendant.

                                  Attached is a small sample project, illustrating this approach in action. We hope you will find it helpful.


                                • Mark OMeara 07.23.2013

                                  I do not understand how the attached sample helps with Caliburn Micro and mapping a ViewModel command to a BarButtonItem command. The sample seems to change a button width.

                                • Hi Mark,

                                  The cause of this behavior is that the EventTrigger for the ItemClick event starts animation of the Width property:

                                  <i:EventTrigger EventName="ItemClick" SourceName="btn1"> <local:BeginStoryBoardAction Storyboard="{StaticResource ButtonSizeAnimation}" /> </i:EventTrigger>
                                  I hope this makes things clearer.

                                1 Solution

                                Creation Date Importance Sort by

                                Hello Magnus,

                                Our developers have been discussing this issue for a month and have decided not to inherit the BarItem class from FrameworkElement. Some reasons prevent us from implementing this feature. First of all, we believe that using commands is more appropriate for the MVVM architecture than the use of EventTrigger. BarItem already includes the Command property. This is a general MVVM approach to using commands. The second reason is that if we make changes in our source code and inherit from FrameworkElement, this will be a breaking change. We may encounter problems that do not expect now. We wish to save our users from breaking changes if it is possible. In our previous post, we attached a sample that illustrates how to overcome this issue right now using the System.Windows.Interactivity assembly. We suggest that you use this solution.

                                Thank you, Marina

                                Show all comments
                                • Péter Jenei 08.13.2012

                                  Hi Marina,

                                  First of all, let me clarify, why I think you are on the wrong way with this:

                                  - You should not decide what is more appropriate instead of your customers.

                                  - As you can see with a Support Center search, many MVVM developers love and want to use Caliburn.Micro's features.

                                  - Last, but not least it's incosistent within your own product: DevExpress.Xpf.Bars.BarItem descends from FrameworkElement in the Silverlight version, while descends from FrameworkContentElement in the WPF version.

                                  Anyway, I created and just published a package to CodePlex which helps developers attaching messages to FrameworkContentElement descendant objects. Anyone, who is interested, can find the Caliburn.Micro.FrameworkContentElement package on CodePlex and NuGet.



                                • Hello Peter,

                                  Thank you for your feedback. This may be very helpful to our users. You are right. Our BarItem inherits from the FrameworkElement class in Silverlight. Our developers tried to inherit from this class in WPF, but encountered problems that caused breaking changes. This can be very painful to our other users. This is the main reason why we postponed this request implementation.

                                • Mark OMeara 07.23.2013

                                  Can you please just implement the correction, breaking change or not.

                                • Ilya (DevExpress Support) 07.24.2013

                                  Hello Mark,

                                  Our developers decided not to implement this functionality for reasons described in the ticket's Answer. Would you please clarify why the approach with System.Windows.Interactivity described in Vito's comment is not suitable to you?

                                  I look forward to your response.

                                • Mark OMeara 07.24.2013

                                  I did above, I do not understand how it relates to a Caliburn.Micro command, also how does it handle enabled/disbled using the Caliburn.Micro naming conventions (e.g. CanSave).

                                • Your goal is not clear to me. Please clarify what you wish to enable and disable.

                                • Mark OMeara 07.25.2013

                                  This support item was generated due to BarButtonItem not supporting the same sort of MVVM features (for Caliburn Micro) as, say, a normal button, or textedit, etc. What I want to do is quite simple, I want the BarButtonItem to behave like a Button with CaliburnMicro MVVM. For Example if the name of the BarButtonItem is 'New' then it needs to call the 'New' method in the ViewModel. Additionally if the ViewModel has a property called 'CanNew' then the BarButtonItem needs to enable/disable based on that. Standard sort of thing really.

                                  I do not understand how the above solution achieves that, instead it appears to animate a button and has no interaction with the ViewModel at all.

                                • To achieve this goal, you can use the BarItem's Command property that can be bound to a command in your View Model. I suggest you review the How to use Commands in WPF article describing how to use this standard functionality. When you use this approach, your button will be automatically disabled as soon as your command is disabled.

                                • Mark OMeara 07.31.2013

                                  This is quite silly. Caliburn.Micro works for all your controls except for this one. The only reason appears to be that you guy made a false assumption about the inheritance. So now I am to ditch the Caliburn Micro conventions and use an ICommand for BarButtonItems only? Really poor guys. Very dissapointing.

                                  How about just fixing it so all your controls are consistent.

                                • I would like to say that the current version of our products allows you to use Caliburn with ease. You may find one of possible approaches on the following page: Caliburn.Micro.FrameworkContentElement. I have tested this approach, and it seems to work correctly - see the attached sample.

                                  Changing BarItem inheritance is not an option at the moment, because there are a few factors which prevent us from implementing this approach:

                                  1. BarItem objects are not controls. They are non-visual objects that define a corresponding element appearance and its response to mouse clicks. A primary difference between a BarItem and a visual control is that the former can be displayed in several different toolbars at once. It is not possible to correctly achieve this goal using a visual control. Our toolbars allow doing this by creating multiple BarItemLink objects. The toolbar system creates visual controls on the fly based upon a combination of Item-ItemLink objects. As you may notice, there is a clear differentiation between visual and non-visual objects, so this does not make sense to make a BarItem object visual. Another reason not to inherit a BarItem from FrameworkElement is that bar items will never be shown.

                                  2. Due to the fact that the same BarItem can be used in several places, if we change its ancestor to a visual object, it will inherit a huge amount of non-used properties. Assume you have found an event or property inherited from FrameworkElement (such as Height, Width, or Margin). You will certainly try it! And when you find that it does not work, you will spend a lot of time to determine the cause of the problem. This will complicate understanding of our controls, make them unclear for many customers (especially for new customers who have just started using our controls).

                                  I am almost sure that the use of the aforementioned approach will bring much more side effects than positive capabilities.