Phone1.800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
Open Menu

Synergex Blog

DevPartner 2015 – WOW!

By Richard Morris, Posted on May 15, 2015 at 6:37 pm


That was the week that was the DevPartner 2015 conference in Philadelphia. Ok, so I’m biased but I really have to say this was one of the best conference weeks I’ve had the pleasure to be part of for many years. There were some really great sessions: The HBS customer demonstration rocked! They came to a conference a couple of years ago, did a tutorial on xfServerPlus and with this new found knowledge (and some PSG guidance) created a cool web bolt-on to their existing Synergy app.

We saw some fresh new faces from Synergex: Marty blasted through the Workbench and visual Studio development environments we provide and showed some really great tools and techniques. Phil gave us a 101 introduction to many of the “must know” features and capabilities of Synergy SDBMS – and of course was able to address mine and Jeff’s performance issues – you had to be there:). Roger demonstrated his wizardry to enlighten everyone as to the issues you need to consider when transferring your data within local and wide area networks – I was the bad router!

Bill Mooney set the whole tone of the conference with a great opening presentation showing just how committed Synergex are to empowering our customers with the best software development capabilities available.

My first day’s session followed and gave me the opportunity to demonstrate how you actually can bring all our great tools together to create true single-source, cross-platform applications which run on platforms as diverse as OpenVMS, UNIX and Microsoft Windows and onto a Sony watch running Google Wear!

Steve Ives went 3D holographic with videos from his recent trip to the Microsoft Build conference that showed just how amazing the Microsoft platform is becoming – and we aim to continue to be a first class player in that arena.

So many of our products are reaching a level of maturity that blows the competition away. Gary Hoffman from TechAnalysts presented a session showing how to use CodeGen and Symphony in the real world and showed just what you can achieve today in Synergy.

Jeff Greene (Senior .NET engineer @ Synergex) and I presented a rather informal (read written the night before) presentation showing the performance and analysis tools in Visual Studio 2015 that you can use to identify problem area and memory leaks in your application. Within minutes Brad from Automated System forwarded me an email he’d just sent to his team:

“At the Synergex conference just this morning, they just showed fantastic new diagnostics tools in Visual Studio 2015.  I just put the Team on the trail of potential memory issues with these new tools in a Virtual PC environment so we don’t alter our current developer stations. This could both reduce the memory footprint and improve performance.” – You can’t beat such instant feedback!

The tutorial time gives attendees the opportunity to play with the latest tools on a pre-configured virtual machine – plug in and code! And we continued the hands-on theme with Friday’s post conference workshop – where we built the DevPartner 2015 App from the ground up!


Thanks to everyone for coming and making the conference such a great success. It’s our 30th conference next year so keep your eyes and ears open for dates and details – it will be a conference not to miss!

Build your own CLR

By Richard Morris, Posted on March 26, 2015 at 1:54 pm


Open source code is all the rage these days, everyone is doing it, even Synergex.  For some years now CodeGen and Symphony Framework have been open source.  They are both available on  What this gives you is the ability to see inside the classes and programs to see, if you are interested, exactly how they are doing what they do. Even Microsoft are joining the open source band wagon – the .NET Framework is open source and the CLR is following!  Where PSG lead, others will follow (LOL – I think that means laugh out loud, so my kids tell me).

Does this mean you are going to grab all the code, build your own CLR and tweak it to make the blue windows green? No, not at all.  What it does mean is that people can now see what’s happening inside the ocne “black box” and move this code to other platforms.  And this obviously helps us Synergy .NET developers.  We can already take advantage of other platforms because of the availability of the .NET framework and CLR components on non-windows platforms.  It’s how we can deploy your next application to that fancy new Android or iOS phone.  It’s how you can take your good received code you wrote 10 years ago, bundle it up into a tablet application with signature capture and have real time “proof of delivery” built into your systems.

Aside from the conference topics there was an interesting question on the Synergy-l list last night.  The request was to display multiple coloured boxes on the screen.  Sounds simple – and using Synergy.Net inside Visual Studio it was!  20 minute later….








All the UI elements (colour, values, images) come from a data bound repository based structure so you could load the contents directly from your ISAM files.  The actual colours and images are selected through switches inside the XAML code based on the values of your synergy data.  I don’t think I’ll be demonstrating this simple example at the DevPartner 2015 conference, but there will be lots of great examples to see, and of course tutorials to step you through how it’s done.  It’s the last day of DevWeek tomorrow which means I’ll be driving my car around the M25 car park trying to get out of central London for hours.  So I’ll make this my last blog from the conference.  As always the conference has been enlightening.


Symphony Bridge

By Richard Morris, Posted on March 19, 2015 at 1:51 pm


For more than 30 years Synergex has enabled developers to take advantage of many different computer operating systems, hardware environments and networking topologies.  Today there are a number of different options to enable connectivity between client applications and services and the Synergy application logic and data.

If it’s a simple case of data on one machine and Synergy application on another then xfServer is the technology of choice.  One quick change to your environment variables and off you go – data being served on a plate.

If you want to move the execution of Synergy logic onto the server where the data is to improve performance while doing complex data searching and analysis, or need to access the application logic from non-Synergy environments like C#/ASP.NET/Java, then xfServerPlus is the perfect fit.  It takes a little more configuring, but is proven and reliable.

Both of these “server” technologies required a certain configuration of your network and are only recommended for use on your internal LAN.  So getting data and logic accessible to clients on the wrong side of your firewall, in a standard and secure way, requires the use of other tools or software.  The general approach is to create a web service to expose all the methods you would like the client to be able to consume.   Once you’ve written this web service you then need to run the Synergy application logic and data access.  You can call back into your traditional ELB’s via xfServerPlus or you could write the server in Synergy.Net and use xfServer to access the data – but stop!  If you do this you run the risk of running out of channels, different processes crashing your common data and other issues. 

Welcome to the Symphony Bridge Server and the Symphony Harmony namespace.  Symphony Bridge provides a RESTful web service layer that allows you to execute your native Synergy.Net application logic and data access from any Synergy supported client consumer.  The Symphony Harmony namespace provides the ability to access your applications database files using SQL syntax and to make remote procedure calls to execute Synergy application logic, without the need to build a web server of your own, because it uses the Symphony Bridge.

We’ll be presenting the new Symphony capabilities at DevPartner 2015 and you’ll get your chance to try them out by working through one of the self-paced tutorials.  You can also sign up for the post-conference workshop to utilise these new capabilities to build a complete client-server application end-to-end.

Reasons to Be Cheerful

By Richard Morris, Posted on December 2, 2014 at 10:44 am


Back in 1979 Ian Dury and the Blockheads wrote a song about all the things that made them cheerful.  Titled “Reasons to be cheerful, part 3” it’s a quick fire list of things in his life that not only made him cheerful, but what he believed made everyone feel cheerful.  As 2014 draws to a close we have our own reasons to the cheerful – the release of Synergy version 10.3.1.

Reasons to be cheerful – One, two, three.

Android Development

Now you are able to take you Synergy code, build it in Visual Studio and deploy to any Android device – that’s your phone or tablet.  Using XAML to define your UI can even enable you to write once and deploy to many different device options including iOS – which is being released in beta mode with 10.3.1.

Improved Developer Experience

Both Workbench and Visual Studio Integration continue to exceed expectations when we talk “developer experience”.  Even better IntelliSence and seamless access to .NET capabilities like LinQ.  Build powerful Portable Class Libraries (PCLs) that can be used to deploy your Synergy logic and data access code on multiple target platforms.

Targeted Runtimes

In Visual Studio you can now install the latest Synergy Language Integration and target an older runtime version, for example install SDI 10.3.1 and target runtime 10.1.1.  This keeps you using the latest tools without the need to immediately update your target platform.

Programmatically Track File Changes

Using the new ChangeTracking class you can now access file snapshots and change tracking information directly from Synergy.

Connection Recovery

xfServer between Windows client and server can now be configured to recover from a network interruption and auto-reconnect.  This development continues to strengthen the robust quality of xfServer.

 Device Licensing

Controlling who’s using your applications is important and Synergex recognises this with the ability to utilise device licensing for your Android and iOS (future release of Synergy) apps as well as your Windows store and desktop programs.

To complement the release of Synergy 10.3.1 the Symphony team has developed a new server component called Symphony Bridge.  Symphony Bridge allows you to communicate via HTTP and HTTPS to a server that is exposing your application logic and data.  Bridge utilises Symphony Harmony which is an SQL command interpreter layer that accepts SQL based commands (selection, store procedure execution, etc.) and performs the required tasks on the remote server.  There will be more about Harmony and Bridge in a future blog post.

For now, let’s sing along with Ian and have “Reasons to be cheerful” with the release of 10.3.

Synergy and XAML in Harmony

By Richard Morris, Posted on October 17, 2013 at 2:23 am


The Symphony Framework is a set of assemblies that aid the development of Synergy .NET applications.  Together with CodeGen they provide a powerful, flexible environment within Microsoft Visual Studio to build great looking windows applications utilising your existing Synergy data and logic.

Windows Presentation Foundation (WPF) is the tool of choice.  The user interface is written in XAML and data bound to your Synergy data exposed through Symphony Framework Data Objects.  It all sounds simple, and it is.  The biggest problem with XAML is that the data binding is performed at runtime, using “magic” strings.  They are “magic” because at runtime they miraculously find the data source you named in the binding “string” and all is well.  However, if you mistype the string then the bindings don’t work, but your application continues to execute – no errors reported, but no data.

To alleviate this problem the Symphony Framework uses CodeGen to build Synergy Repository based Styles.  Styles allow you to define the “style” of a control, for example the type of input control, it’s size, field entry limitations, drop-down list bindings, error information, etc.  Once defined you can reference these styles in your XAML UI code and utilise them.

In Visual Studio 2010 this worked nicely: referencing your styles worked and you could apply styles to the input controls, but there was no editor assistance – you needed to remember the style names for things to build and run correctly.

And then came along Visual Studio 2012 and things really didn’t work at all.  The XAML referencing syntax was changed and broken in a big way.  Some referencing worked in the XAML designer and failed at runtime, and others the reverse – meaning you couldn’t design your UI at all.  Big problems!

But now Visual Studio and the Symphony Framework are back in harmony.  The upcoming release of Visual Studio 2013 is a must for anyone doing any .NET development, it’s a triumph over VS2012!  As well as the XAML referencing being fixed there are some cool new features that really make Symphony Framework development even easier.  One such feature is that the XAML editor is now aware of all your referenced style, making the selection of the right style easier than learning your scales.






And using the right style ensures you have the right binding: hey-presto no more binding issues!

Synergy 10.1.1b is going to be release to coincide with the release of VS2013 so bookmark your diary and ensure you upgrade to the latest versions of both.

If you would like to see examples of Styles in action you check out my video at

Symphony Framework Basics: Control Styling

By Richard Morris, Posted on September 6, 2013 at 5:05 am


In my previous article (Symphony Framework Basics: Data Binding) I demonstrated how to perform simple data binding between your XAML UI controls and your Data Objects.  This article demonstrates how to build powerful styles to define and control your user interface and provide automated data binding to your Data Objects.

Before we look at styles, let’s recap how we do data binding.  Consider the following simple repository structure;

Record group_record

GROUP_ID    ,A20   ; (1,20) group id

DESCRIPTION ,A100  ; (21,120) description

When created as a Data Object this creates two properties;

public property Group_id, a20

public property Description, a100

In the XAML code we can data bind the properties exposed by the Data Object to standard UI controls;

<TextBox Text=”{Binding Path=Group_id, Converter={StaticResource alphaConverter}}”/>

<TextBox Text=”{Binding Path=Description, Converter={StaticResource alphaConverter}}”/>

There are a number of issues here, and not all of them are obvious.  Although we have performed the data binding, there is no code in the XAML to prevent the user typing more characters than the underlying data allows.  The Group_id property for example only allows up to twenty characters, so we need to add code to prevent more being entered.  In the repository we’ve defined the field to only contain uppercase characters and again the XAML is not honouring this requirement.  When a field is in error, for example a required field that is blank, the underlying Data Object exposes this information, but we are not utilising it here.  Also, controlling if the field is read-only, if entry is disabled, etc.  All these setting and more can be configured against the field in the Synergy Repository.

Using CodeGen and the correct Symphony templates we can generate styles that define exactly how we require field entry to be controlled.

Generating the style files is very simple.  The syntax to execute CodeGen with is;

codegen -s GROUP -t Symphony_Style -n GroupMaint -ut ASSEMBLYNAME=GroupMaint -cw 16

One interesting item on the CodeGen command line is the “-cw 16”.  This simply defines the standard width as 16 pixels for each character and is used when defining the size of a control.

The generated style file contains individual styles for each field in the repository structure, as well as a style for the prompt.  Here is an example of a prompt style;

<Style x:Key=”Group_Group_id_prompt” TargetType=”{x:Type Label}”>

<Setter Property=”Template”>


<ControlTemplate TargetType=”{x:Type Label}”>


Content=”Group ID”

IsEnabled=”{Binding Path=Group_idIsEnabled}”>






And a field style;

<Style x:Key=”Group_Group_id_style” TargetType=”{x:Type symphonyControls:FieldControl}”>

<Setter Property=”FocusVisualStyle” Value=”{x:Null}”/>

<Setter Property=”Focusable” Value=”False”></Setter>

<Setter Property=”Template”>


<ControlTemplate TargetType=”{x:Type symphonyControls:FieldControl}”>

<TextBox Name=”ctlGroup_Group_id”

Text=”{Binding Path=Group_id, Converter={StaticResource alphaConverter},



Validation.ErrorTemplate=”{StaticResource validationTemplate}”




IsEnabled=”{Binding Path=Group_idIsEnabled}”

IsReadOnly=”{Binding Path=Group_idIsReadOnly}”



ToolTip=”{Binding RelativeSource={RelativeSource Self},Path=(Validation.Errors), Converter={StaticResource errorConveter}}”>




<DataTrigger Binding=”{Binding Path=Group_idIsFocused}” Value=”true”>

<Setter Property=”FocusManager.FocusedElement”

Value=”{Binding ElementName=ctlGroup_Group_id}”></Setter>


<DataTrigger Binding=”{Binding RelativeSource={RelativeSource Self},Path=(Validation.HasError)}” Value=”True”>

<Setter Property=”TextBox.Background”>


<LinearGradientBrush StartPoint=”0.5,0″ EndPoint=”0.5,1″>


<GradientStop Offset=”0.2″ Color=”WhiteSmoke” />

<GradientStop Offset=”3″ Color=”Red” />














This code may look a little verbose but enables a number of capabilities, including;

  • Data binds the underlying UI control to the Data Object property
  • Control features like field length, character casing, read-only, etc.
  • The Tooltip is used to display any error information if the field is in error.
  • The control background colour is made red if the field is in error.

Once you have created your styles and added them to your Visual Studio project you can then reference and use them in your UI design.  To reference the style;

<ResourceDictionary Source=”pack:/GroupMaint;component/Resources/Group_style.CodeGen.xaml”/>

Each style is based on a control in the Symphony Framework called “FieldControl” which can be found in the Symphony.Conductor.Controls namespace.  You must add a reference to this namespace in your XAML code;


Now you can reference the FieldControl and apply the required style to it;

<symphonyControls:FieldControl      DataContext=”{Binding Path=MasterData}”

Style=”{StaticResource Group_Group_id_style}”>


And to add the prompt, or label style use;

<Label Style=”{StaticResource Group_Group_id_prompt}”

DataContext=”{Binding Path=MasterData}” />

Because the styles are linked to the same property in the same Data Object when your code disables the input control the prompt will be greyed out as well.

The code snippets here are just part of the overall solution.  To see the full details you can watch a short video at This article convers styling of the user interface.  The next article will demonstrate using all of the difference Synergy fields types and utilizing controls like date pickers, check boxes, etc.


Symphony Framework Basics: Simple Data Binding.

By Richard Morris, Posted on August 28, 2013 at 3:06 am


In my previous article (Symphony Framework Basics: Data Objects) I introduced you to the Symphony Data Object.  These Data Objects are at the root of a Symphony Framework development.  This article demonstrates how to data bind the exposed field properties on your Data Object to user interface controls.

Before we deep dive into data binding let’s take a minute to understand how we are going to craft our new user interface (UI).  For a Windows Presentation Foundation (WPF) desktop application we will be building our UI in XAML.  As defined by Microsoft:

“XAML is a declarative mark-up language. As applied to the .NET Framework programming model, XAML simplifies creating a UI for a .NET Framework application. You can create visible UI elements in the declarative XAML mark-up, and then separate the UI definition from the run-time logic.”

To enable the separation of logic we utilize a concept called data binding.  Data binding provides the ability to bind a UI control to a dynamic piece of data.  This data binding can only occur when you expose your individual data fields as properties. For each field in your repository structure the Data Object exposes a read-write property of the same name, starting with an uppercase letter – case is VeRy iMpOrTaNt in WPF!

Consider the following simple repository structure;

Record group_record

GROUP_ID    ,A20   ; (1,20) group id

DESCRIPTION ,A100  ; (21,120) description

When created as a Data Object this creates two properties;

public property Group_id, a20

public property Description, a100

The first thing to note here is that the property types are Synergy types.  The underlying data is not transformed by the code generation process or the Data Object.  The actual data type being exposed here is a Synergex.SynergyDE.AlphaDesc.

Our UI is going to be written in XAML.  Now XAML understands all standard .NET types like String, Integer, etc. but does not know about a Synergex.SynergyDE.AlphaDesc type so when we data bind to this property we need to utilize a converter to convert from the base, or exposed type, to a type that can be understood by XAML.

This sounds a little complicated but it’s not, and actually gives you complete control over how your UI controls do data binding.  Let’s look at an example.  Consider you have a field called “credit_exceeded” which in your synergy program is defined as an “a1”.  The exposed Data Object property would be called “Credit_exceeded”, exposed as an a1 and the allowable values for the field are “Y” for yes and “N” for no.  Ideally “Credit_exceeded” would be exposed as a boolean.  But by doing so you would have to change any existing synergy code that wanted to use this property.  You would also have to define logic in the Data Object to perform the transformation between the Y/N values and True/False.  By using a converter when you perform the data binding you can choose how you wish to see the data.  A modern UI would most likely bind the Credit_exceeded property to the IsChecked property of a UI CheckBox control.  But some users may wish to continue to see and enter “Y” or “N” and so you can data bind to a standard UI TextBox.  Alternatively you could expose a UI DropDown control with “Yes” and “No” options, bound to the values “Y” and “N”.  By allowing the UI designer in the XAML to utilize converters and exposing the raw Synergy data is a very powerful capability.

So, back to our XAML design.  Our Data Object was built from the repository structure and contains the two properties;

public property Group_id, a20

public property Description, a100

We need to be able to convert from Synergex.SynergyDE.AlphaDesc to String so that we can data bind to simple UI TextBox controls.  The Symphony Framework provide a number of default converters which can be found in the Symphony.Conductor.Converters namespace.  In your XAML code you need to reference the converters;

<ResourceDictionary Source=”pack:/SymphonyConductor;component/Resources/Converters.xaml”/>

Once we have referenced the Symphony Framework converters we can use them to convert from our base Synergy type to any standard .NET type.

<TextBox Text=”{Binding Path=Group_id, Converter={StaticResource alphaConverter}}”/>

<TextBox Text=”{Binding Path=Description, Converter={StaticResource alphaConverter}}”/>

And you have data bound the Data Object properties to the UI controls.  If the data within the Data Object changes, the UI is notified and updated.  As data is changed through the UI, the underlying Data Object is updated.

The code snippets here are just part of the overall solution.  To see the full details you can watch a short video at article convers the basic data binding capabilities of the Symphony Framework.  In my next article we shall demonstrate how to style your UI by generated repository structure based styles and utilize them in your UI XAML code.

Symphony Framework Basics: Data Objects.

By Richard Morris, Posted on August 22, 2013 at 6:12 am


The purpose of the Symphony Framework is to enable you to expose existing Synergy data and logic in a way that can be utilised in a Windows Presentation Foundation (WPF) desktop application.  This is achieved using Symphony Data Objects.  These Data Objects are at the root of a Symphony Framework development.

Creating a Symphony Data Object is very simple, but before we talk about how, let’s look at why.  Synergy data is rather different to the data you find in other applications/databases.  All synergy data is an alpha.  When I talk about Synergy data I mean the information we store and move around the application. I’m not referring to individual elements of data that you can define using the “data” statement – these are different and do allow you to create a data entity that is not an alpha.  So, that’s cleared up what “data” in Synergy is….  It’s all just an alpha.  These alpha data areas are what we manage in our SDMBS data files. Just try reading from your file into an integer: %DBL-E-ALPHAXP, Alpha expression expected!  The compiler is very clever and allows you to re-map this alpha data to anything you desire, with a few exceptions, and this is done by declaring “record” areas.  Your record area can overlay this alpha data in any way you require, and can even overlay the overlays.  This overlaying is simply remapping how we want to expose or access the individual bytes of the alpha stream of data.  It’s actually quite cool and very powerful.  Now you have your alpha data – but in your Synergy program you are accessing portions of the data as different types like decimal, integer, alpha, etc. and your programs rely on this ability.  So where do we store these overlay definitions of our alpha data – in your Synergy Repository of course!

Now back to our Symphony Data Objects.  As I mentioned, creating them is a breeze.  You simply use CodeGen, the right Symphony Framework template, and your Synergy Repository structure.  The syntax is very easy:

codegen -s GROUP -t Symphony_Data -n PartMaint -prefix m

And you have your structure based Symphony Data Object.

Assuming you have referenced the required Symphony Framework assemblies in your Synergy.NET Visual Studio project your Data Object code will just build.

Understanding the Data Object is really quite simple as well.  There are a number of aspects to be aware of….

  • There is a property called SynergyRecord.  This is a property that exposes the underlying “alpha” data area.  You can use this property to populate the Data Object, for example, when you have read a record from a file.
  • Each field in your repository structure is exposed as a read-write property which allows access to the individual fields.
    • You can data-bind to these properties from your WPF user interface (XAML) code.  More about this in my next article!
    • You can also access this “field” data from your existing Synergy code.
    • Additional powerful capabilities of your Data Object include:
      • IsDataValid is a boolean value indicating if the data within the Data Object passes the basic validation rules you have defined in your repository structure.  For example, a “required” field must have a value in it otherwise the Data Object is considered IsDataValid == false.
      • The object conforms to the property notification sub-system of the Model-View-ViewModel design pattern for WPF development.
      • Individual fields in your repository structure additionally expose IsEnabled, IsReadOnly and IsFocused properties that help you control the User Interface.

You can watch a short video at that walks you through the steps for creating Symphony Data Objects and building them into your Synergy .NET Visual Studio project.  In the next article I’ll demonstrate how easy it is to data bind UI controls to your Data Object properties.

Paradise by the dashboard light.

By Richard Morris, Posted on March 7, 2013 at 11:08 pm


For many years we have had the ability to expose Synergy data and logic through xfServerPlus which can be consumed, processed and displayed by cool Windows programs.  But for me there has always been the “single thread” bottleneck.  I’ve wanted my Windows applications to respond when the user drags the mouse, clicks a button, sorts a grid, at the time the event happens, and not when the program has caught up doing its background actions.  Calling a remote method generally “hangs” the program until that operation has completed and this is because it’s being performed on the UI thread.  And while the UI thread is busy calling into your xfServerPlus libraries and waiting for a response it blocks any user interaction so your application becomes unresponsive.

The answer is to utilize threads.  Threads are separate processing channels that can run simultaneously.  Your application always has at least one thread – the UI thread.  But if you have a language that can allow multithreading then utilising this to perform background tasks on other threads frees your UI thread to continue being response to the user – its job really!

Welcome to Synergy.NET!  Totally written in Synergy.NET and utilising the Symphony Framework I’ve written a fully functional interactive dashboard:


The user can fully define the record selection criteria and then issue the “Select” of the data.  This selection is performed on a background thread.  This means as the results are being returned from the remote Synergy DBMS file via xfServer the list is populated and the user can begin navigating the items within it.  While the list is loading, the user can select an item even if the list load is not complete.  At this point a number of background threads become active – each one loading data from different files via xfServer.  The various lists are populated “in real time” and the application remains responsive – all the lists can be “loading” at the same time.

If the user clicks another item in the list the executing threads are instructed to “stop” and then the selection process restarts based on the newly selected master record.

Using the Symphony Framework and building my Synergy Repository based Data Objects using CodeGen I was able to quickly build the core components used in the Dashboard including the thread based selection code.

All this functionality is available in the latest V10.1 release of Synergy. To find out more details and to see multithreaded processing in action book your place at the upcoming DevPartner Conference at

The changing face of data.

By Richard Morris, Posted on January 14, 2013 at 3:02 am


With the eagerly anticipated release of Synergy/DE version 10 we now have the ability to track and manage changes to Synergy DBMS data files.  This new feature, Change Tracking, gives you the ability to track and monitor records within a file that have been modified, added or deleted.

Using the snapshot facility you can start a new snapshot within a file and begin your applications normal processing.  Any file updates are records against the current snapshot.  There can only ever be one active snapshot within a file so as soon as you start a new snapshot, all previous ones become an historical record of the changes made to the file.  In code you can access any existing snapshot within a file to trace the activity using the new Select class.

A recent development for a customer required code changes to a number of programs.  All the programs together defined a process and it was imperative that my changes didn’t break that process.  I wanted to be able to test the changes to the data after running each program and not just when I’d run all the programs for the process.  With Change Tracking this was a very easy task.  I simply created a new snapshot across all my files before running each program.  Using the Symphony Framework and CodeGen I created a simple program that displayed the records within a particular snapshot, so I could easily see what changes the program had made.  If a program didn’t do what I had expected (I intentionally coded in a bug just to check this!) I could simply rollback the current transaction, fix the program and continue.  I no longer have to restore the data and start my testing from the beginning.

You can see just how easy it is to utilise Change Tracking by watching a short video I’ve uploaded to YouTube.  Enjoy!

There are many applications for Change Tracking, and at this year’s DevPartner conference I’ll be exploring this new feature in detail – including having attendees help me demonstrate many of the capabilities!

Making Maintenance Easy!

By Richard Morris, Posted on September 19, 2012 at 6:38 am


The Symphony Framework continues to develop and expand its capabilities.  The latest version ( has a number of extensions that allow you to build powerful single file/structure maintenance programs.  These programs, known as CRUD style programs (,_read,_update_and_delete), allow the maintenance of data within the file.

Creating these “simple” programs can often be a time consuming process.  You need to create the User Interface, showing what fields the user can see and amend.  You’ll need a lookup as well, so the user can search for existing records.  Your users will need the ability to add new records, and of course be able to remove records from the file.

This is where the Symphony Framework and CodeGen can “take the strain”.  Today you can write a complete CRUD program, including a totally flexible query lookup mechanism without writing a single line of code!

The Symphony Framework is packed full of powerful templates that help you utilize CodeGen to generate all the components to build modern Windows Presentation Foundation based desktop CRUD applications in Synergy .NET.  Templates include the ability to display and format the “key” and “data” views of a repository structure.  These “views” are then used to build the user interface.

The lookup capabilities allow the user complete flexibility when they wish to search for existing records in the file.  The criteria “view” is totally customisable by the user and they can select any fields, which you’ve allowed access to, within the structure to select matching records.  The resulting list of matching records can again be fully tailored to meet the user’s requirements.  Columns can be hidden or revealed as required and they can also be reordered and sorted.  Selecting a record from the list allows you to amend the details, and then return you back to the populated query list.

The complete program provides a graphical menu and toolbar so the user can easily navigate the various CRUD options available.  There are also “hint” icons that help the user to understand the capabilities the programs provide.

You can view a video that demonstrates these powerful new features of the Symphony Framework on YouTube by clicking this link: Happy viewing!

Keeping Focus

By Richard Morris, Posted on August 15, 2012 at 6:56 am


In a traditional Synergy application you have usually always had total control over the user interface.  Your program code has displayed the field prompts on the screen, or loaded and placed your UI Toolkit windows.  With the user interface defined and displayed it’s again your application code that controls what the user can do, and when.  If they enter an invalid value in a field the code would usually display some sort of message and force the user back into the field, never to leave until a valid (according again to your application logic) value has been entered.  And the UI Toolkit continues this tight coupling between field validation, user notification and UI navigation control.

As software development moved forward with Microsoft WinForms based applications this trend generally followed.  The code behind each control knows everything about the control, and as such can force the focus back to the field when required.

With the advent of the Windows Presentation Foundation (WPF) application things changed dramatically.  Of course you can still bind code-behind to your controls on your WPF forms, but that’s really not the point of WPF – if you have code behind then the chances are you are going something wrong.  The most powerful feature of WPF is data binding.  Data binding is the ability to bind an object property value to a field or control on your user interface.  Messaging between the UI and the application ensure that your data is kept synchronised.  This is the Model-View-View Model (MVVM) design approach, which is the cornerstone of a Symphony Framework based Synergy .NET WPF application.  MVVM provides for a platform that fully (and correctly) disconnects the user interface from the application data and logic.  But if the application has no knowledge of the UI, and the UI has no knowledge of the application logic, how can your programs force fields on your forms to have focus?  There are many better ways to provide user feedback than to display modal messages and force the user back into the field entry, which I’ll discuss in a future blog.  But there will always be someone who needs to be able to re-focus a field within the user interface from within their program.  Code-behind will be required, yes?  No, not if you use a Symphony Framework Data Object!

Symphony Framework provides the ability to request focus be given to whatever control you are using to bind against a particular Data Object property.  And focusing that control is the responsibility of the View, or XAML code – there is no code-behind requirement.  From within you application you can set a property in the Symphony Framework Data Object indicating that you would like the control associated with that data property to be given focus.  In the XAML you listen for the request and honour it or not, at the discretion of the UI designer.  And that request can bound to simple controls or complex containers.

Do you want to know how?  Instead of writing up lots of code I’ve prepared a short video that demonstrates this powerful new feature of the Symphony Framework.  You can view the video on YouTube by clicking this link: Happy viewing!

Symphony Framework and CodeGen Helping Customers Migrate to a WPF UI

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

Steve Ives

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.

Recent Posts Categories Tag Cloud Archives