Open Menu

Synergex Blog

Symphony Framework and CodeGen Helping Customers Migrate to a WPF UI

By Steve Ives, Posted on August 1, 2012 at 4:20 pm

Richard Morris and I have just returned from a seven-day consulting engagement with a customer, and I wanted to share with you some information about our achievements during the visit. The customer we visited with is one of our larger ISV’s and has an extensive Synergy application, much of which is implemented using the Synergy/DE UI Toolkit. As with many applications, life started out on cell-based systems many years ago, but for many years now it has been deployed exclusively on Windows systems.

SymphonyLogoThe customer in question had listened to us talking about Symphony Framework and CodeGen at the Chicago DevPartner conference, and was interested in how they might be able to leverage them to accelerate the process of updating the look and feel of their applications by replacing their existing UI Toolkit user interface with a Windows Presentation Foundation (WPF) user interface. Needless to say we were eager to help, because we believe we have a great story to tell, and some great tools to share!

Most in the industry would agree that WPF represents the current “state of the art” when it comes to implementing user interfaces for Windows Desktop applications. We have had our eyes on WPF for some time now, and have been learning about it’s capabilities. We have also been encouraging customers to consider WPF as a great way of updating the UI of their existing applications, or implementing the UI of new applications. And thanks to new features in Synergy/DE 9.3 and 9.5 there are a couple of great ways of doing just that.

For existing applications the Synergy/DE .NET Assembly API can be used to embed WPF directly into existing applications. Of course one of the main benefits of doing so is that the application can be enhanced screen-by-screen, without the need for extensive re-writes and long development cycles. Of course for new development Synergy .NET can be used to build all-new applications with a WPF user interface. There is also a realistic migration path between the two; you can chose to start off by enhancing screens in an existing application via the .NET Assembly API today, and then ultimately migrate the entire application to a native Synergy .NET solution. All very “doable”.

Before I get into the specifics of our tools and what was achieved, there is one more thing that I should mention. Just as most industry pundits would agree that WPF is the way to go for Windows Desktop applications, most would also tell you that there is a specific WAY that WPF applications should be implemented; it’s called the “Model-View-ViewModel Design Pattern”, which is often abbreviated as MVVM.

A design pattern describes a methodology for implementing a software solution to a certain problem. The MVVM design pattern sets out a way of designing software such that there are clear lines of demarcation between code that deals with different parts of an application. Specifically it prescribes how the “Model” (code which implements an applications data definitions and business logic) should be separated from the “View” (code which implements the applications user interface), and how these two entities should be joined by the “ViewModel”. We’ve talked quite extensively about MVVM in the past, and there are lots of great resources available on line, so I don’t intend to go into more detail here. Suffice it to say that adhering to the MVVM design pattern is strongly recommended when implementing WPF applications.

I mentioned earlier that we have been focusing on WPF for some time now, and also on MVVM. But as well as just learning about the technologies and patterns, Richard Morris has been “beavering away” at his home office in England pondering the question “how can we help our customers to easily use WPF and MVVM in the context of their existing Synergy applications?”. Once he’d finished pondering the question, he then started coding the answer … and the Symphony Framework was born.

So just what is the Symphony Framework and how can it help you? Well in a nutshell, Symphony Framework is an MVVM Framework (library) which can be leveraged by Synergy developers to significantly simplify the process of implementing WPF user interfaces in their Synergy applications, while at the same time adhering to the best practices prescribed by the MVVM design pattern. Symphony Framework can be used to incrementally add WPF UI to existing applications in conjunction with the .NET Assembly API, and it can be used to implement all-new Synergy .NET applications with a WPF UI.

Some areas of Symphony Framework are designed to specifically address the somewhat unique challenges associated with migrating UI Toolkit applications, but the framework is in no way limited to working only with UI Toolkit applications. To cut a long story short, if you have an existing Synergy application and want to “spiff it up” with a fabulous new WPF UI, then Symphony Framework might just become your new best friend!

I’m not going to go into a huge amount of detail about HOW this all takes place, but I do want to briefly describe some of the common steps. For the purpose of this illustration I’ll ask you to imagine an existing UI Toolkit application (but remember, it doesn’t have to be Toolkit), and imagine that I want to do a gradual screen-by screen migration to a WPF UI, initially driven by the existing application (via the .NET assembly API). What might the steps be? Well, for each screen (or window) we might:

  • Create a “Model” class that describes and exposes the underlying data to be worked with. Model classes inherit a lot of functionality from base classes in the Symphony Framework.
  • Create a “View” using WPF.
  • Create a “ViewModel” that exposes the information in the model to the view, and provides the functionality needed to service the requirements of the view. ViewModel classes also inherit a lot of functionality (in some cases all of the required functionality) from base classes in the Symphony framework.

The code for all of the steps described above would be implemented in Synergy .NET and would be compiled into a .NET assembly.

  • Use the .NET assembly APIs “GENNET” tool to create Traditional Synergy “wrapper” classes that allow these various components to be accessed and manipulated from the existing Traditional Synergy application.
  • Create a “Manager” class (we’re still trying to figure out what to call this bit!) which contains the bulk of the code required to instantiate and drive the underlying .NET code.
  • Modify the existing application to present the new WPF UI instead of the existing UI, primarily by accessing functionality exposed by the “Manager” class.

You might be tempted to see this last bullet point and think “there is is, modify our existing code, that’s the hard and time consuming part”! But don’t let this thought put you off, believe it or not the changes that typically need to be made to the existing code are relatively small and painless. This is due in no small part to the things that the Symphony Framework is doing for you!

During our visit with our customer we initially worked on what it would take to replace existing “lookup” routines with new WPF implementations. In a UI Toolkit application a lookup routine is often accessed via a “drill method” associated with an input field, and often uses a combination of input processing to allow the user to define search criteria, and list processing to present matching results. When the user picks an item the associated value is returned into the input field. We managed to get this process down to a fine art. and this is where CodeGen comes in.

CodeGen1We were able to create CodeGen templates which allowed us to generate most of the code that was required to “switch out” a UI Toolkit lookup for a WPF lookup. We were able to code generate 100% of the Model class, 100% of the View class, 100% of the ViewModel class, and 100% of the “Manager” class. All that remained was to modify the existing application to utilize the new code instead of the existing UI Toolkit UI. Figuring out how to do the first lookup probably took in the order of half a day, but with the process and CodeGen templates in place, the next four lookups probably took around 20 minutes each to implement. We left it at that, because we were confident that we had the process down at that point.

Then we moved on to other areas, attacking a “maintenance” type program. The process is actually remarkably similar, and actually not that much more complex, again because much of the base functionality required is inherited from the Symphony Framework. By the end of our engagement we pretty much had that process down also, and again much of the required new code was being code generated, leaving only relatively minor changes to the existing application to be made.

Of course not all aspects of an application are as simple to deal with as the scenarios that I just described, some parts of an application and its UI get pretty complex, and it isn’t always possible to code generate all of the required components, and it isn’t always possible for the Symphony Framework to provide all of the required functionality in the form of base classes. Programmers still have a role to play, and thank goodness for that! But I do believe that the tools that Richard and I have developed can play a significant role in projects of this type, and it’s not just theory, we just proved it!

Actually that’s probably not a totally fair statement for me to make, as there are several other customers who have already used the Symphony Framework with great effect. Just as there are many customers who already use CodeGen to generate many different types of code to address various application needs. But Richard and I don’t often get to work together on a project, and this is perhaps the first time that we have really tried to use both of these tools together and push them HARD to see what could be achieved. And I for one am confident that everyone involved, including our customer of course, was pretty impressed with the results.

By the way, if your goal is to build an all-new WPF application directly in Synergy .NET, while retaining and re-using large portions of your existing code, then the steps aren’t that different to those described above. The Models, Views, ViewModels and “Manager” classes would be essentially the same, but would be driven by a Synergy .NET WPF application rather than by a DBR application via the .NET Assembly API. We actually proved this recently while preparing a proof of concept demo for another customer. Having been provided with the code for a small sample application, and some sample data, we migrated the UI of the application to WPF using the steps described above. Once the application was working with a new UI, and armed with the classes that we had just created, we were able to re-purpose those classes without change in a 100% Synergy .NET WPF application. In all the process took about four hours … but probably could have been completed faster had we not been sat at a bar at the time! This really is pretty cool stuff!

Before finish I do want to stress one more time that the Symphony Framework and CodeGen tools are not just about UI Toolkit applications on Windows. Symphony Framework helps you migrate to an ultra-modern WPF UI on Windows, but the starting point could easily be an application that runs on a cell-based platform today. And CodeGen can be and is being used on all systems supported by Synergy.

Release Notifications for CodeGen and Symphony Framework

By Steve Ives, Posted on July 31, 2012 at 5:19 pm

At the DevPartner conference I told people that in order to receive notifications for new releases of the open source CodeGen and Symphony Framework projects they should “Follow” the projects on CodePlex.

It turns out that “following” a project doesn’t send release notifications. If you want to get release notifications then you must go to the “Downloads” page for each project and subscribe for notifications. If you are interested in either of these two projects then I would recommend that you do just that, as we’ve done some great enhancements to both recently, and there are more great things still in the pipeline.

The downloads page for CodeGen is at and the downloads page for Symphony Framework is at

I Command Thee

By Richard Morris, Posted on June 12, 2012 at 7:10 am

At the DevPartner conference in Chicago ( we announced an open source project called Symphony Framework.  The Symphony Framework project is a Synergy .NET based set of libraries that assist with the migration of traditional Synergy cell based and UI Toolkit applications to a native .NET Windows Presentation Foundation (WPF) desktop application.  The concept of the Symphony Framework is to simplify the Model-View-View Model (MVVM) design pattern and make it easy to migrate your traditional Synergy code.

An important aspect of any program is responding to user requests.  In a UI Toolkit program this is typically based on menu entries – even ones that don’t exist and are signalled in code using M_SIGNAL().  A WPF desktop application is no exception and commanding is an important aspect of the program.  In the MVVM model you utilise an interface called ICommand.  This interface provides for three very important elements.  Firstly, a hook, or entry point to be executed when the command is processed.  Processing a command can be assigned to the click of a button on the UI, it could be the navigation event around a list, or even a line of code in your program.  Secondly the ICommand model enables a status enquiry point –where the bound UI control can interrogate the command object and determine if it is enabled for execution.  Generally a UI control bound to a command object will render itself differently depending on the executable state of the command.  For example a button will appear greyed out and not clickable.  And thirdly is the ability to notify the UI control that the executable status of the command has changed, which causes the interrogation of the command object to determine is executable state.

The Symphony Framework exposes a number of command types, the easiest to use is the GenericCommand, which can be found in the Symphony.Conductor.Commands namespace.  This class utilises the ICommand interface and makes coding commands very simple.  You can create individual command objects or one generic command.  Here is an example of defining a generic command within your View Model class that can be bound to any number of UI control.

Firstly, reference the correct namespace:

Now create a private class member:

Now expose a public property which we can bind out UI control to:

Note in this code that if the private mCommand class field is null we create an instance of the GenericCommand class and assign it.  We also define the logic to execute when the command is processed.  Now we can write the event handler:

Notice the routine signature.  The “parameter” string argument will be set to the value you assign to the bound command in the UI.  As an example, here we are defining three buttons which all data bind to the Command property:

By using the CommandParameter attribute we can assign the required “operation” to each bound command.  Now we can extend the logic in our event handler routine:

This example shows you how to easily utilise the GenericCommand class within the Symphony Framework.

There are many more examples that you can review from the Examples Explorer which is available when you install the full Symphony Framework.  If you are interested in looking at the Symphony Framework code and becoming part of the development community search for “Symphony Framework”.


Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives