Log In
Home
Support
Demos
Documentation
Blogs
Training
Webinars
[Expand]General Information
[Collapse]WinForms Controls
  Prerequisites
 [Expand]What's Installed
 [Collapse]Build an Application
  [Expand]Choose Application UI
   Data Management Controls
  [Expand]Printing and Exporting
  [Collapse]WinForms MVVM
   [Collapse]Concepts
     Conventions and Attributes
     Fluent API Support
     Data Bindings and Notifications
     Commands
     Services
     Behaviors
     Layer Communication. Messenger
     View Management
     ViewModel Management
   [Expand]Design-time Support
   [Expand]Tutorials
  [Expand]Skins
  [Expand]Localization
  [Expand]Right-to-Left Layout
   Redistribution and Deployment
 [Expand]Controls and Libraries
 [Expand]Common Features
  Get More Help
 [Expand]API Reference
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Document Server
[Expand]Reporting
[Expand]Report Server
[Expand]Dashboard
[Expand]eXpressApp Framework
[Expand]CodeRush
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation

Commands

The common way to perform certain actions on the WinForms platform is to handle the specific event and execute required methods within the event handler. For instance, if you need to show a message box when a button is clicked, handle the ButtonClick event and call the MessageBox.Show method.

However, this pattern breaks the idea of separating Views and ViewModels in MVVM, since your View gets code behind that should be placed within a ViewModel or Presenter. The MVVM pattern suggests a different approach: your actions should be encapsulated into a specific object defined elsewhere. This object is bound to a specific UI element and clicking (checking, modifying, etc.) this UI element triggers the object, which performs the desired functionality. This leaves your View free from the business logic code. Such objects are called Commands.

Since the WinForms platform does not provide commands, using the DevExpress MVVM Framework, which features commands of multiple types and classes, is helpful when developing MVVM applications.

Expanded Delegate Commands

MVVM Best Practices Demo

The text below has a related example in the DevExpress 'MVVM Best Practices' demo.

Group: API Code Examples
Module: Commanding
Example: Delegate Commands
17.2 Demo Center: Launch the demo

Delegate commands are simple commands, designed for synchronously executed actions. In a simple scenario, the command is defined as a DelegateCommand object only with an Execute function.

To bind a command, you can use the BindCommand method, available for most DevExpress UI controls (buttons, check boxes, bar items, etc.).

The DelegateCommand class contains other constructors. Using them, you can define a command that has:

  • a related CanExecute function that controls this command's and the related UI element's availability;
  • a parameter, passed to the command and processed by it;
  • the parameter and the CanExecute condition.

If you define DelegateCommands within your ViewModel, they must be used as the return values of specific properties and constructed by specifying delegates to the Execute and CanExecute methods. The command is then exposed to the View using a read-only property that returns a reference to an ICommand (see the code below).

Expanded POCO Commands

MVVM Best Practices Demo

The text below has a related example in the DevExpress 'MVVM Best Practices' demo.

Group: API Code Examples
Module: Commanding
Example: POCO Commands
17.2 Demo Center: Launch the demo

Since the DevExpress MVVM Framework supports POCO classes, your commands can also be defined as void methods with none or one parameter within such classes. The framework is smart enough to recognize such methods and treat them as commands.

To bind these commands, use the MvvmContext component's API.

Features like CanExecute functions and parameters, are also supported by POCO commands.

The code below illustrates a common workflow when implementing POCO commands. The DoSomething command (1) is a POCO command that performs certain actions on collection entities (e.g., selected grid control rows). The currently selected entity is kept as the bindable SelectedEntity (2) property's value. Whenever this property changes its value, its OnSelectedEntityChanged callback (3) is automatically triggered. This callback fires the standard DevExpress POCO RaiseCanExecuteChanged method (4) for the DoSomething command. When called, this method re-checks the CanDoSomething method's return value (5) and updates the DoSomething command's availability accordingly.

Expanded Asynchronous Commands

MVVM Best Practices Demo

The text below has a related example in the DevExpress 'MVVM Best Practices' demo.

Group: API Code Examples
Module: Commanding
Example: POCO Asynchronous Commands
17.2 Demo Center: Launch the demo

Asynchronous commands are designed to fulfill delayed or continuous tasks. If void methods are automatically transformed into simple commands, you need to utilize a method of the System.Threading.Tasks.Task type to create an asynchronous command.

The binding itself remains unchanged - you still use the BindCommand method.

Asynchronous commands usually take some time to be performed. Thus, in most scenarios, developers give their end-users the ability to cancel these commands (e.g., cancel downloading a file, unpacking an archive, etc.). To do so, make sure that the methods that perform asynchronous actions include the cancellation check.

If you have such a command, you can use the MvvmContext component's BindCancelCommand method to specify a UI element that will cancel the running asynchronous command.

As you can also see, CanExecute methods are not manually defined for the async command, nor its cancellation. The Framework does all the work automatically and locks the UI element that calls the async command till this command is finished (or canceled). The UI element that cancels the async command is also disabled automatically until the target command is started. So all you have to do is define your Task method and bind commands using the MvvmContext API - the DevExpress MVVM Framework will do the rest for you.

Expanded Legacy Commands

MVVM Best Practices Demo

The text below has a related example in the DevExpress 'MVVM Best Practices' demo.

Group: API Code Examples
Module: Commanding
Example: Legacy Commands
17.2 Demo Center: Launch the demo

Same as with data binding, you do not need to have all ViewModels built according to POCO concepts to be able to use the DevExpress MVVM Framework. Your commands can be defined within separate custom classes. For these commands, use the BindCommand method of the target UI element, same as you did with delegate commands.

How would you rate this topic?​​​​​​​