Software Package for Forced Draft Units Calculations for KMZ JSC — Stage 4

Client

MST Company has successfully completed the latest development stage of the calculation system for KMZ JSC.

This stage primarily involved upgrades to the user interface, while also introducing new functionality. Let us walk through the details.

User Interface

Typically, adapting the interface to new components proceeds without significant issues. However, in this case, unexpected challenges arose, requiring additional effort and careful attention.

In this release, we fully transitioned the application’s interface to utilize the MahApps MahApps.Metro. Metro library, making it the primary focus of this stage.

Typically, modifying properties like Margin or Padding in element styles is straightforward. However, implementing more complex behaviors can present numerous challenges within MahApps. A striking example of this is handling mouse hover effects on an element with custom colors.

While creating a custom theme for the framework would have been a possible solution, doing so for a single customized element would have been overly time-consuming. Deviating from the standard usage of the library often required delving into its source code, which is far from efficient in the broader development process.

That said, MahApps.Metro also has significant advantages. It includes a variety of specialized components absent in stock WPF, along with a customizable icon library and numerous helpers. These features greatly simplify the process of altering the behavior of interface elements.

In summary, while MahApps.Metro poses certain challenges, it offers many positive features that enhance development efficiency.

Auto-Update System

During the program’s operation, it became evident that too much time was spent updating to new application versions.

Even minor updates should occur with minimal time investment to avoid disrupting workflows.

To address this, the current version includes a built-in automatic update feature, ensuring seamless and time-efficient upgrades.

Initially, we designed the update system based on the AutoUpdater.NET library. This library offers great flexibility in configuration and performed well after being integrated into the project. However, several issues critical to this project surfaced.

The primary functionality typically required from an auto-update system is the ability to download and install a new version of the application. In addition to this, the client required an additional feature: the automatic relaunch of the application after the update.

This seemingly simple functionality, unfortunately, could not be achieved with AutoUpdater.NET. It also became apparent that AutoUpdater.NET had issues when installing the application using msiexec.

As a result, we decided to abandon AutoUpdater.NET and develop the update process entirely in-house.

Minimum Requirements for the Update System:

• A server to store archives of different application versions.
• Metadata about the current version, also hosted on the server.
• The ability to download metadata and the application archive.

The first step was to configure the server. The implementation is straightforward: we used nginx for file distribution with access restricted to authorized users only.

On the application side, we developed a dedicated updater application to inform users of the current stage of installation. We also implemented a library that encapsulates all the logic for working with the server and msiexec into a user-friendly API.

To handle metadata, we created a simple and convenient YAML file containing several parameters:

The configuration file resembles that of AutoUpdater.NET but is much more readable compared to XML.

While downloading metadata from the server and checking the version is straightforward, installation through msiexec presents its own challenges.

To implement automated installation (using the /q parameter), a custom installer is recommended. This is because background software installation must be transparent to the user to prevent any unwanted programs from being installed. Consequently, both the installation and uninstallation processes should require user confirmation. This approach was agreed upon with the client, as they were comfortable with the need for a few confirmation clicks to complete the installation.

Another issue arose during the installation of new versions: the msiexec utility does not support upgrading by installing a new version over the old one. To address this, it was decided to remove the current version before installing the new one. This is achieved by using the application’s GUID to ensure proper uninstallation.

Additionally, a lightweight application is required to monitor the installation process. This application allows the user to track progress and, in case of unexpected issues, send installation logs for troubleshooting.

However, this setup introduces a minor complication: the monitoring application is part of the main software package, which is removed before the new version is installed. To resolve this, the installer temporarily copies itself to the %TEMP% directory and performs the installation from there.

Measurement Units Management in the Software

At the time of writing this case study, the implementation of measurement units was still in its early stages, and the development process was not yet finalized. However, several interesting aspects can already be highlighted.

The primary point of interest here is the implementation of measurement unit handling.

For instance, when a user changes the pressure measurement unit from Pascals to Bars in the program settings, all pressure-related values throughout the program must be recalculated accordingly. This setting applies only to the current user.

From a coding perspective, this is achieved by introducing an intermediary class. This class can modify the displayed value and is aware of the measurement unit it represents.

This design allows for seamless switching between measurement units while ensuring that the class triggers an OnChangeProperty event, causing the interface to reflect the updated value.

Additionally, each unit of measurement is implemented with a conversion to the base unit of its group. For the Pressure group, for example, the base unit is Pascal.

These conversions are handled by two classes: one for constant-based conversions and another for formula-based conversions. The latter is currently only used for converting Celsius to Fahrenheit.

Gas Mixture Editor

Typically, the most complex development tasks occur within the program’s calculation module. However, in the Gas Mixture Editor, we encountered an intriguing challenge that was more interface-related than code-related.

The issue involved displaying values in the Ratio column based on the selected measurement unit (percentage or absolute values). The complexity arose from the limitations of DataGrid, which does not allow dynamic switching of the bound variable in XAML alone.

During development, we attempted to implement a custom CellTemplate that would display the appropriate field based on the selected unit. However, WPF proved insufficiently flexible for this approach without breaking various styles.

As a result, at this stage of development, the task was resolved by creating a second DataGrid. While this solution works, it must be acknowledged that it is not the most elegant approach.

User Management

From the very beginning, the application was designed to support multiple users, though this functionality was rarely utilized in its initial stages.

Now, we have reached a point where access control has become a critical system feature, making further development unfeasible without it.

As a result, we restructured the user model to enable flexible access control settings with the ability to easily integrate new modules into the system.

While describing the basic functionality seems unnecessary—it follows a standard CRUD approach—the access management module deserves special attention.

In addition to creating users, the module’s core functionality includes grouping permissions by modules. Implementing this required designing a data structure capable of supporting an arbitrary number of sections with any level of nesting.

Ultimately, access permissions were implemented using strings with delimiters. For example, to verify access to element B within section A, it suffices to reference a string like "A.B" and sequentially check the accessibility of each element.

Initially, it was assumed that implementing this functionality might require a more complex interface solution. However, in practice, a customized TreeView component with a tailored template proved sufficient.

Postscript

At this stage, the client is successfully utilizing the functionality, while we have begun further expanding the application’s capabilities. With many exciting tasks ahead, our team remains dedicated to implementing them effectively.