Don Wibier's Blog

August 2016 - Posts

  • WPF: Asynchronous server mode for lookup editors (new in v16.1)

    In our v16.1 release we have introduced a very nice feature to improve the U.I experience on the LookUpEdit, ComboBoxEdit and ListBoxEdit.

    We call it asynchronous server mode and it means that we use our server mode functionality for the data being shown in the dropdown pane.

    Server mode is a very clever way of selecting small chunks of data to populate the visible area of the control. All data-aware operations like sorting, filtering and grouping are being performed in a background thread. This results in an instant feedback U.I. experience for the end-user as the editor and application will always remain responsive for user actions.

    When such an operation is in progress, we provide visual feedback in the form of an animation to indicate the status of the operation.

    When editors operate in server mode they also support auto complete when the dropdown is closed.

  • Webinar: Using DevExpress MVVM Magic with WPF

    This week, I presented a webinar about our MVVM framework which ships with our WPF control suite. In case you missed it, you can watch it here.


    What is MVVM and why?

    MVVM stands for Model-View-ViewModel and it is a design pattern which requires you to make some architectural choices before you start on a project. I will only spend a little time on the ‘why’ since there are tons of great articles out there doing a way more detailed job.


    The most important advantages in my opinion are:

    Seperation of concerns

    In this case, the View (U.I.) does not have any direct relation with the DataLayer (Models). The ViewModel provides all the presentation logic and accesses the DataLayer if needed.

    In most applications, data is stored in a relational database. The structure of your database is in most cases optimized to select and/or update information as quickly as possible. Also in most cases, this is not the most optimal way for presentation purposes. The ViewModel gives us the possibility to transform the data coming out of the DataLayer into an optimized (different) structure for presentation purposes.

    By using this approach, we can use one of the very powerful features of the WPF platform – databinding. The View databinds certain elements in the U.I. to properties or commands exposed by the ViewModel. As a result, in most cases there is no code-behind in a View.


    Another cool side effect of this pattern is that – because the ViewModel doesn’t care what is bound to it – we can replace the View with a UnitTest. Since all presentation logic is coded in the ViewModel, this means that we can UnitTest the presentation logic.

    Why did we build such a framework?

    While WPF is designed to support a lot of aspects of the MVVM design pattern, some things do require some coding in the ViewModels. To give you an example: A ViewModel is unable to interact directly with the UI, but what happens when some validation code in the ViewModel needs to raise a confirmation on the UI?

    This is implemented through Services and Behaviors and is something available out of the box through our framework. There are a couple more difficulties in this loosely coupled architecture which are managed easily through the framework.

    We also provide you with some really awesome design-time support built in to easily bind all kinds of things to the ViewModel. This support is provided with all DevExpress WPF controls.

    This all results in less code in your ViewModels which keeps things nice and clean.

    An introduction of the Framework

    The MVVM framework is convention based. This means that there are certain guidelines you need to follow and by doing so, you’ll be able to build applications in less time.

    In the webinar I created a ViewModel based on a number of those conventions. The bare minimum code for a ViewModel looks as follows:

    public class TrackViewModel
        public virtual TrackInfo Track { get; set; }
        [ServiceProperty(SearchMode = ServiceSearchMode.PreferParents)]
        protected virtual IMessageBoxService MessageBoxService { get { return null; } }
        protected TrackViewModel()
            // for test purposes only !!
            Track = new TrackList()[15];
        public static TrackViewModel Create()
            return ViewModelSource.Create(() = > new TrackViewModel());
        public bool CanResetName()
            return Track != null & amp; & !String.IsNullOrEmpty(Track.Name);
        public void ResetName()
            if (Track != null)
                Track.Name = "";

    In the code there are a couple of interesting points.

    • The class is decorated with the [POCOViewModel]
    • Properties (for binding purposes) are marked virtual
    • The constructor is marked protected which means that we cannot instantiate such a ViewModel directly
    • There is a public static Create method which instantiates a new instance of this ViewModel through the ViewModelSource factory
    • The method bool CanResetName has a relation with method ResetName

    The creation of an instance of this class through that factory is essential for the magic to happen. What happens under the hood is that the framework creates a new ViewModel class which is derived from our ViewModel. In this derived class, we add all kinds framework related things to the ViewModel. For instance, we create Commands for public methods, we set constraints depending on the results of those bool Can… methods.

    Also the IMessageBoxService MessageBoxService property - which just returns null - will have changed behavior in the derived class.

    Once we have set everything up according to those conventions (and did a build), we’re able to switch to the View. Through the Task Menu of any of the controls, we’ll be able to use those design-time features which come with the framework.


    During the webinar I introduced a second View + ViewModel and I demonstrate how one ViewModel activates another and synchronize some data. I also show how easy it is to map events (from the grid) to commands in the ViewModel by binding expressions.


    If you want to perform a test on one of the ViewModels, you can setup a test like:

    class TrackViewModelTests
        const string INITIAL_TRACKNAME = "My Test Track";
        const string MODIFIED_TRACKNAME = "My Modified Test Track";
        protected void SetUp()
            // initialize your test here
        public void TestResetNameCommandNo()
            var vm = TrackViewModel.Create(new TrackInfo() { Name = INITIAL_TRACKNAME });
            var serviceContainer = (vm as ISupportServices).ServiceContainer;
            IMessageBoxService msgSvc = new DummyServiceForMessageBox(MessageResult.No);
            //Testing the ResetName behaviour while clicking No on the confirmation dialog...
            Assert.That(vm.Name, Is.EqualTo(INITIAL_TRACKNAME));

    Do note that the DummyServiceForMessageBox can be a simple class which looks like:

    internal class DummyServiceForMessageBox : IMessageBoxService
        private readonly MessageResult resultToTest;
        public DummyServiceForMessageBox(MessageResult resultToTest)
            this.resultToTest = resultToTest;
        MessageResult IMessageBoxService.Show(string messageBoxText, string caption,
            MessageButton button, MessageIcon icon, MessageResult defaultResult)
            return this.resultToTest;

    Because these services are interfaced based, we can simple change the implementation of this DummyServiceForMessageBox from showing the dialog to an immediate Yes or No.

    The Demo Project

    The project I have created during the webinar is available on github at:

    I have also included an NUnit test project to demonstrate how to test one of those ViewModels.

    Let me know what you think of the framework and if you are ready for a deep-dive webinar!

  • Creating Desktop Apps for Windows, Mac OS and Linux with DevExtreme

    Last week I did a webinar on creating desktop applications with DevExtreme and Electron. In case you missed it, it is available on our YouTube Channel


    This was also one of the first webinars where a swift introduction on DevExtreme with Visual Studio Code, Git, Node/NPM (Node Package Manager) and the Command-Line was performed. In case you have heard the term NPM, but don’t know exactly what it is; NPM is for Node what Nuget is for dotNet.

    For all of you wanting to redo the demo project on your own – a simple ToDo app – I have written down the steps that where performed in the webinar.


    Before opening a command prompt, make sure you have the latest versions installed of the following:

    With these tools setup, you can fire up a command prompt and create a folder which will hold the project and navigate into it.

    Make sure you use some short folder structure like C:\Src\App1, since the MAX_PATH value in Windows is reached fairly quickly when using NPM and node modules!

    C:\cd \Src
    C:\Src>md App1
    C:\Src>cd App1

    No project template?

    Because Visual Studio Code doesn’t support Project templates out of the box, I decided to use a GitHub repo as project template by cloning it.

    The repo can be found at:, and we can clone it to our App1 folder with the following command at the command prompt:

    C:\Src\App1>git clone . 
    (don’t forget the dot at the end)


    Once the cloning is finished, we can start VSCode like:

    C:\Src\App1>code .
    (mind the dot)

    The package.json already includes the required NPM packages but if you’re new to NPM, it might be worth taking a look at it. You could e.g. change the application name and version number.


    If you’re used to the full Visual Studio experience and have used the project template which comes with DevExtreme, you might recognize the folder structure as well as several files provided with this clone.

    One thing which is slightly different, is the lack of JavaScript files in the /js folder and the references in the index.html. This is because we will use NPM to get all dependencies for this project.

    Because we made a fresh clone, we need to get all those dependencies through NPM. This is done by the following command:

    C:\Src\App1>npm install


    After some time – depending on your internet speed – NPM finishes. In our case it comes with a couple of warnings which we can safely ignore. This project will not use Angular, Globalize or Webpack.

    Now, we can start the project in our browser by issuing the command:

    C:\Src\App1>npm start

    The package.json will be checked for the scripts / start setting which will execute the lite-server and show a browser with our SPA (Single Page Application).


    Lite-server is a small web-server – much like IIS Express for ASP.NET development – to test SPA web-based apps. It is written in Node by John Papa and Christopher Martin. It is specified as dev-dependency in the package.json, so it was downloaded and configured during our npm install command. It has a couple of convenient features like browser-sync. This feature monitors the source folder for changed files and automatically refreshes the browser used for testing.

    We will not be using this since we’re going to create a desktop app. Let’s hit Ctrl+C in our terminal window to exit the lite-server.

    Getting Electron in the project

    So, let’s turn this into a Desktop app by adding the Electron package to the project. This is done by entering the following command:

    C:\Src\App1>npm install electron-prebuilt –save

    This will download the Electron package and stores the dependency in our package.json file so it will look like this:


    The npm install only caused step 1 to be added to the package.json file because of the –save option. Since we’re not using the lite-server anymore, we could either remove the lite-server dev-dependency manually from the package.json file or we could issue the command:

    C:\Src\App1>npm remove lite-server –save-dev

    If we want the electron runtime to boot up when we issue the npm start command, we need to change the scripts / start option manually to electron main.js as mentioned in step 3.

    Initializing the Electron app

    So now everything is almost setup to run our JavaScript SPA as a desktop application. If you look closely to the start configuration and next to your project folder, you might notice that one file is missing – main.js.

    The main.js file is a JavaScript file containing the bootstrap code for initializing the main process of the desktop application. It initializes the bare chromium browser window and determines what to do when certain thing concerning that window are happening – like minimizing / maximizing and closing the window.

    The content of this file is pretty much the same as found on the Quick start guide available at the

    const electron = require('electron');
    // Module to control application life.
    const app =;
    // Module to create native browser window.
    const BrowserWindow = electron.BrowserWindow;
    global.settings = {
        databaseFolder : app.getPath("documents")
    // Keep a global reference of the window object, if you don't, the window will
    // be closed automatically when the JavaScript object is garbage collected.
    let mainWnd;
    function createWindow() {
        // Create the browser window.
        mainWnd = new BrowserWindow({ width: 1200, height: 700 });
        // and load the index.html of the app.
        // Open the DevTools.
        // Emitted when the window is closed.
        mainWnd.on('closed', () => {
            // Dereference the window object, usually you would store windows
            // in an array if your app supports multi windows, this is the time
            // when you should delete the corresponding element.
            mainWnd = null;
    // This method will be called when Electron has finished
    // initialization and is ready to create browser windows.
    // Some APIs can only be used after this event occurs.
    app.on('ready', createWindow);
    // Quit when all windows are closed.
    app.on('window-all-closed', () => {
        // On macOS it is common for applications and their menu bar
        // to stay active until the user quits explicitly with Cmd + Q
        if (process.platform !== 'darwin') {
    app.on('activate', () => {
        // On macOS it's common to re-create a window in the app when the
        // dock icon is clicked and there are no other windows open.
        if (mainWnd === null) {

    The code inside the main.js file is actually being executed in the Node context of an Electron application. One of the nice things in Node is the use or the require(…) construct to include npm packages.

    A nice side-effect is that we can also use the require method inside our render process(es) to include npm packages. Render processes are basically the rendering of our SPA app – html/CSS/JavaScript assets inside the Chromium window.

    The reason that we can use require(..) in our render process is because Electron adds a couple methods to the JavaScript Window object, which also allows us to exchange data between the main and render processes and to facilitate the Electron API to access local resources and O.S. specific features.

    JQuery comment

    Those extra methods mentioned before are causing JQuery to fail while initializing inside an Electron window for various reasons. This can be fixed easily by changing the index.html script sections at the bottom of the page. Let’s also make use of the require construct:

    Original code in index.html:
        <div class="dx-viewport"></div>
        <script src="./node_modules/jquery/dist/jquery.js"></script>
        <script src="./node_modules/knockout/build/output/knockout-latest.js"></script>
        <script src="./node_modules/devextreme/dist/js/dx.all.js"></script>
        <script src="./js/db.js"></script>
        <script src="./index.js"></script>
        <script src="./layouts/Desktop/DesktopLayout.js"></script>
        <!-- ViewModels -->
        <script type="text/javascript" src="./views/home.js"></script>
    Electron changes in index.html:
        <div class="dx-viewport"></div>
            //because of electron, we need to include jQuery slightly different
            window.$ = window.jQuery = require("jquery");
            window.ko = require("knockout");
            var dxapp = dxapp || {};

    With these modifications in place, we're ready to boot up our desktop app by entering the command:

    C:\Src\App1\npm start

    Final comments on the webinar project

    In the webinar, I showed how to use a local SQLite database to store the ToDo items. For this I replaced the /js/db.js file with the one hosted on github. I also added the npm package sqlite-sync to the project with:

    npm install sqlite-sync –save

    This script also requires the app.json file to be present in the root folder of our project and it shows you how to work with configuration settings in an Electron app.

    The db.js script shows you a way on how to create a DevExtreme Datasource with a custom store which supports paged results, sorting and filtering. This functionality is used in the /views/tasks.js file to create a proper viewmodel for the view /views/tasks.html file. Here I added a dxDataGrid widget.

    The entire project created during the webinar is also available on github and can be tested with the following commands in your terminal window:

    C:\Src>md app2
    C:\Src>cd app2
    C:\Src\app2>git clone .
    C:\Src\app2>npm install && npm start

    In case you want to know more on Electron, please check their documentation at . This also contains information about packaging you application for the specific platforms, best practices and things to consider when building a cross-platform app.

    Don’t forget to test it on a Linux machine as well as a Mac and do let me know what you have created with DevExtreme and Electron!

  • DevExtreme: New client-side export for Charts and Data Visualization

    DevExtreme comes with some really powerful Charting and other data visualization controls like Maps, Gauges and Range widgets. One of the issues faced in the pre-v16.1 versions of our suite was that exporting such a widget to e.g. PNG, JPG or PDF was a bit of a tedious job.

    You would need the specific widget bound to a dxExporter widget on the client, and a specially customized PhantomJS instance configured on the server:


    Besides the fact that you would need this extra server, you can imagine that this process takes some time to configure and test.

    Exporting in v16.1

    In our v16.1 release we have added export functionality to all the widgets. This means that there is no need for this custom PhantomJS server, and that it will work pretty much out of the box.


    How does it work?

    If you want to enable export functionality for a specific widget, the only thing you need to specify in the configuration object of the widget is:

    options = {
        export: {
            enabled: true

    What about customization?

    Just like the older releases, v16.1 supports exporting as well as printing to JPG, PNG, GIF, PDF and SVG.


    You can even specify a default filename of the export – even without extension – by specifying the fileName property. We’ll add the extension to the filename automatically depending on the chosen format.

    options = {
        export: {
            fileName: "Sales2016ByMonth"

    In the v16.1 release, we added a number of additional features such as specifying the background color for an exported chart:

    options = {
        export: {
            backgroundColor: "#282828"

    This is great for creating a uniform look or complying with your corporate identity.


    Menu enhancements

    In previous versions, the export menu was provided by the dxExporter class. To add this menu to your widget, you would add a reference to that visualization widget in the dxExporter configuration object. To specify a custom menu or to call exporting/printing via custom events on your page, you would have to use the dxExporter API.


    We have made this way easier with v16.1. Since all the widgets have the export functionality included, they also include a default export menu. This menu will be shown automatically if exporting of the widget is enabled.


    Because this menu is now part of the widget, we make sure that it is perfectly aligned and positioned inside the widget.

    All this out-of-the-box behavior is part of the exporting API which comes with the visualization widgets. This gives you the possibility to customize and fine-tune several exporting options according to your needs.

    chartInstance.exportTo("myExample", "pdf");


    The new client-side exporting features in v16.1 are easier and faster to setup. They also allow you to change several aspects of the default export behavior.

    Let me know what you think of this!


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners