You can use the Windows WPF client to run a metadata-driven Windows desktop user interface against a Turnkey server; this page is for developers who need to understand how the client receives data, sends edits, and builds its UI.

How the client works

The Windows WPF client has two logical parts that work together:

1. A synchronization component maintains a local replica of the information in the ViewModel.
2. A UI component reads ViewModel metadata and creates the WPF menus, views, editors, and other widgets that users work with.

The client does not treat the WPF controls as the source of truth. Controls are data-bound to the local ViewModel replica. The server processes changes and distributes the resulting state changes back to clients.

Part	Responsibility	What you see
Local ViewModel replica and synchronization	Listens for changes from the Turnkey server, maintains a local information tree, queues user changes as commands, and merges server changes into the local tree.	A bound editor displays the current value and updates when the server reports a change.
Metadata-driven WPF UI	Reads metadata for global actions and the views to display, then creates WPF UI elements bound to the local information tree.	Main-menu actions, edit boxes, and other widgets appear from the ViewModel definition.

Part 1: Local ViewModel replica and command flow

The first part of the client is a two-threaded listener and information-tree builder. By streaming changes from the Turnkey server, it keeps a local replica of the ViewModel information tree.

When a user changes a value in that replica, the client generates a command. Commands are queued and sent to the server in the order in which the user created them. The client sends them at the earliest possible time, while preserving that order.

The server processes each command against its main ViewModel-based information tree. Processing a command can produce both the requested change and side effects. The server collects the resulting changes as server commands. The client fetches those commands when it has reason to ask, then merges them into its local ViewModel replica.

Example: editing a bound value

Assume a displayed ViewModel contains an editable customer name.

1. The WPF editor is bound to the local replica and displays the current name.
2. The user changes the name in the editor.
3. The client creates and queues a command for that change.
4. The server handles the command and updates its main ViewModel information tree.
5. If server-side processing changes other values as a consequence, those changes are included in the server commands.
6. The client retrieves and merges the server commands, so its local replica and bound WPF controls reflect the server-processed result.

This flow also means that changes made elsewhere can become visible in the WPF client when the corresponding server changes are retrieved and merged.

Part 2: Build the WPF user interface from metadata

The second part of the client reads metadata that describes:

• Available main-menu actions, called global actions.
• The ViewModel views that the client is to display.

This metadata is a condensed representation of the ViewModel definition created in MDriven Designer. The client uses it to build a WPF user interface, including edit boxes and other UI widgets. Each widget is data-bound to the local ViewModel replica maintained by the synchronization component.

Example: a global action and a view

If the ViewModel definition supplies a global action, the client can expose that action in the main menu. If it supplies a view with editable attributes, the client can create the corresponding bound editors. When the user invokes the action or edits an attribute, the client creates commands; it does not directly update the server's main information tree.

Define the actions and views in MDriven Designer, then let the client consume the resulting ViewModel metadata. For a custom WPF runtime host that loads ViewModel definitions and initializes WPF UI handling, see Documentation:Using WECPOF in runtime. For a starting point for a WPF-based MDriven Framework project, see HowTos:First MDriven Framework project.

Application background ViewModel

Name a ViewModel DefaultBackgroundViewModel when you want it to be used as the application background.

For example, if your application needs a background-level ViewModel that is available independently of the currently displayed view, create and name that ViewModel DefaultBackgroundViewModel. The Windows WPF client recognizes that name as the application-background convention.

Download the client source code

The WPF client code is open and available as a dated download package.

1. Open MDrivenTurnkeyVersion.xml.
2. Read the build date in that file.
3. Insert that date into the download file name: https://www.MDriven.net/PublicDownloads/MDrivenTurnkeyClientCode_YYYYMMDD.zip.
4. Download the resulting package.

For example, the currently documented file-name pattern is MDrivenTurnkeyClientCode_YYYYMMDD.zip. Build dates change, and older download files can be removed, so use the version XML file to determine the available package rather than relying on an older link.

Related WPF topics

• Use Documentation:WPF Debugger when you need to include the runtime WPF debugger in a WPF application, including applications that mix Windows Forms and WPF.
• See Documentation:WPFMahappAndGantt for a Turnkey WPF rich-desktop application topic.
• See Documentation:SignalR and Realtime for SignalR compatibility and connection troubleshooting relevant to realtime communication.

See also

• Documentation:WPF Debugger
• Documentation:Using WECPOF in runtime
• HowTos:First MDriven Framework project
• Documentation:WPFMahappAndGantt
• Documentation:SignalR and Realtime