Open Menu

Synergex Blog

Are you ready for the demise of Windows XP?

By Roger Andrews, Posted on August 28, 2013 at 10:28 am

As Microsoft has stated and many other companies have echoed (see links below), the end of life for Windows XP is April 2014. Yep, in just 7 months, Microsoft, anti-virus vendors, and many software vendors (including Synergex) will no longer provide support or security patches for IE and XP. And the end of life for Windows Server 2003 will follow soon after.

Why is this so important? And, if what you’re using isn’t broken, why fix it?

Let’s consider, for example, a doctor’s, dentist’s, or optician’s office running Windows XP and almost certainly Internet-connected – in fact, probably using an Internet-based application. All it takes is an infected web site, a Google search gone astray, or a mistyped URL, and the PC is infected – INCLUDING all of the office’s confidential medical data. Plus, most offices allow their workers to browse the Internet at some point in the day – to catch up on e-mails and IM, conduct searches, surf eBay, etc. If the office is running XP after 2014, it is almost certain that it will be open to infection by a rootkit or other malicious software, because the malware authors will take advantage of every vulnerability not fixed by Microsoft due to the end of life. Add the fact that the antivirus vendors will also reduce or eliminate support, and you have a mass Bot-like infection waiting to happen. Once a system gets a rootkit, it’s nigh on impossible to remove it without a wipe clean. To further complicate things, it usually takes a boot-time scan from a different device to detect many of these infections.

Further, while Windows XP had an impressive 13-year run, it is far less secure than later operating systems, and the hardware it runs on in many cases is also at the end of its life.

If you or your customers are running Windows XP or Server 2003, it’s time to upgrade to a more modern, more secure operating system like Windows 7. At least you can rest assured that Microsoft’s monthly Patch Tuesday will provide protection with security fixes in conjunction with your anti-virus vendors to protect sensitive information and keep the business running.–08-april-2014–08-april-2014



Symphony Framework Basics: Simple Data Binding.

By Richard Morris, Posted on 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.


Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives