Open Menu

Synergex Blog


Conference Time

By Richard Morris, Posted on March 23, 2015 at 2:26 pm

Day one and a 9:30 start, which is quite early for a Monday morning – and I have just hustled my way through the London underground commuter traffic!  Front row seat for the Xamarin multi-targeting apps workshop, and the presenter is a fellow “Evangelist” so things are looking good.

My goal for today is to squeeze as much knowledge from James, the Developer Evangelist from Xamarin, to ensure everything we are doing at Synergex is going to take us down the multi-targeting utopia highway.

DevWeek in London is an annual conference I try to attend because over the years it’s given me many thought provoking ideas that have made their way into Synergy, Symphony and the applications I write and assist on.  I’m especially looking forward to this year because everything is no longer just about C#, it’s now about multi-platform targeted development – you know, just like what we have been doing with Synergy for 30 years!!

Today it’s a pre-conference Xamarin workshop showing how to provide true native applications on android, iOS and Windows without compromising the UI or having to duplicate your application code across multiple development projects.  The trick is Portable Class Libraries (PCL’s) – once you have these you can plug them into your chosen UI project (Android, Windows, iOS).  Of course Synergy allows for the creation of these PCL’s so out-of-the-box your development team have the tools to “go mobile”.

Many years ago Synergex developed the UI Toolkit – and I know many people reading this will still have applications running using it.  It provided a single source for UI design that targeted multiple platforms.  You could write your UI pieces into a script file which would be “compiled” on the target platforms and the same Synergy code would run and display according to the host environment – OpenVMS and UNIX was “green screen”, Microsoft Windows was just that, native Microsoft Windows.

Today’s multi-targeting tools come from Xamarin and are built into Microsoft Visual Studio and Utilise the Microsoft .Net Framework – just like Synergy.  It provides developers with the ability to write-once-deploy-many across all the latest must-have devices including iOS, Android and Windows Phone and Store.  And did I mention Google Wear?

As a Synergy developer you are perfectly placed to take full advantage of these opportunities.  As well as being able to build new applications from Synergy templates, built into Visual Studio for Android and iOS, you can also plug in your Synergy Portable Class Libraries directly into Windows Phone and Store applications.  You could even be sending push notifications to the latest Google Watch technology on your wrist, if that’s what your application needs.

We will be showing you just how easy it is to create great cross-device apps using Synergy and the latest Xamarin tools at this year’s DevPartner 2015 conference.

And if you want to get right up to speed on all things Synergy don’t forget to sign-up for the pre and post conference workshops.  These workshops will take you from zero to hero when it comes to building great Synergy applications using all the latest tools and techniques, and understanding what all the buzz words and jargon mean.


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.


The changing world of agile product releases

By Roger Andrews, Posted on December 10, 2014 at 10:16 am

The world of enterprise software has changed for everyone with the introduction of device-first applications. Devices can include PCs, laptops, tablets and smartphones. The days of operating system and developer tools releases every two years, or even annually, have gone. The competitive nature of the competing Android, iOS, Windows, and Linux environments, with developer tools supporting all of these platforms, means the OS and tools vendors are adopting an agile approach to release cadences with monthly updates that are not just hotfixes and security updates. The agile vendor release process is now designed to get product updates and improvements out faster, knowing that if something breaks, it can be updated the following month, especially with developer tools.

For example, when Apple releases a new phone/tablet, they update their development stack. This is usually a forced update, and application developers always want to support the new hardware and current iOS release that is automatically available to all devices. This has the knock-on effect that all layered tools (for example Xamarin tools) also have to update to support the new Apple release, usually on the day the release ships. Then companies like Synergex have to update their tools, layered on the layers below them.

The newly announced Windows 10 will have fast and slow cadences for enterprises to choose, but Synergex will need to test for the fastest cadence to ensure compatibility. Visual Studio updates ship as CTPs monthly, with quarterly release track updates. For non-Windows development, Xamarin provides bi-weekly updates for the whole stack for iOS and Android.

So what does this mean to the Synergex customer base? Some Synergy customers do not update their Synergy versions regularly. If you are one of these customers, and you move into the world of devices, you will also need to move into this agile development mindset. Just as you are forced to accept monthly .NET Framework, Java, and security updates, you will also have to accept regular Synergy updates.

With Synergy/DE 10.3.1, Synergex has taken a new approach to help customers needing to keep up with the agile world we live in. Our Visual Studio .NET product set no longer includes the traditional Synergy runtime packages. This allows us to ship hotfixes and continual product updates matching those of the products on which we layer as frequently as bi-weekly, while keeping the traditional runtime and tools at a more stable level. We realize that due to its nature, this agile process has the potential to introduce bugs, and sometimes there will be a code-breaking change that requires a quick fix, but we believe it’s necessary to align with other vendors in this regard. The Synergy device runtimes for iOS and Android are also NuGet packages, allowing us to update them independently of the core Synergy product as new features and support are required. Customers choose whether to take the latest runtime packages on a per-project basis. Finally with 10.3.1 Synergy .NET, we allow the development tools to generate code that’s compatible with earlier versions (10.1.1 for 10.3.1), so customers can take advantage of the latest tool and code generation improvements without having to update every customer’s Synergy/DE installation.

In conclusion, the new device-first world is changing the way we develop and ship software, and all who participate in this world will need to change with it. Synergex has been making changes to meet this challenge, and we can help you meet that challenge while still providing stability to your end users.

For more information about Synergy/DE 10.3.1, visit the Synergex web site.

 

 


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.


New Code Exchange Items

By Steve Ives, Posted on September 23, 2014 at 7:59 pm

Just a quick post to let you know about a couple of new items that will be added to the Code Exchange in the next day or so. I’m working with one of our customers in Montreal, Canada this week. We’re in the process of moving their extensive suite of Synergy applications from a cluster of OpenVMS Integrity servers to a Windows environment. We migrated most of the code during a previous visit, and now we’re in the process of working through some of the more challenging issues such as how we replace things like background processing runs and various other things that get scheduled on OpenVMS batch queues or run as detached jobs. Most of these will ultimately be implemented as either scheduled tasks or Windows Services, so we started to develop some tools to help us achieve that, and we thought we’d share 🙂

The first is a new submission named ScheduledTask. It’s essentially a class that can be used to submit Traditional Synergy applications (dbr’s) for execution as Windows Scheduled Tasks. These tasks can be scheduled then kicked off manually as required, or scheduled to run every few minutes, hours, days, months, etc. You also get to control the user account that is used to schedule the tasks, as well as run the tasks. The zip file also contains two sample programs, one that can be run as a scheduled task, and another that creates a scheduled task to run the program.

The second submission is called Clipboard, and you can probably guess it contains a simple class that gives you the ability to programmatically interact with the Windows Clipboard; you can write code to put text onto the clipboard, or retrieve text from the clipboard. Again the submission includes a small sample program to get you up and running.

Hopefully someone else will find a use for some of this code.


Breaking News … a New Life for OpenVMS?

By Steve Ives, Posted on July 31, 2014 at 4:15 pm

It seems like there is new hope for those organizations still running OpenVMS, after HP recently announced a partnership with a company called VMS Software Inc. (or VSI). There is now talk of adding support for Intel’s Itanium “Poulson” chips by early 2015, as well as the upcoming “Kittson” chip. There is talk of new versions of OpenVMS, and even mention of a possible port of OpenVMS to the x86 platform.

More information here:

http://www.computerworld.com/s/article/9250087/HP_gives_OpenVMS_new_life


CodeGen Training Videos

By Steve Ives, Posted on April 28, 2014 at 7:36 pm

I finally got around to something that I have been meaning to do for a while, creating some short training videos for CodeGen. Just five videos right now, but I have a growing list of subjects for future videos.

You can view the videos on the Synergex Channel on YouTube.

Please subscribe to the YouTube channel to receive notifications when new videos are added.


The Synergy DevPartner Conference: There’s no “one-way” about it

By William Mooney, Posted on April 23, 2014 at 11:23 am

With the 2014 Synergy DevPartner Conference right around the corner, I have been doing some reflecting on how our mission statement, “Advancing Applications. Partnering for Success,” applies to the conference. On the surface, a conference seems like a one-way conversation: the conference host presents information to attendees, who (hopefully) absorb it. However, over the past 28 years (!) of hosting the DevPartner Conference (formerly SPC), I have come to really appreciate the element of partnership involved in the DevPartner Conference—a partnership that transforms a few days of knowledge transfer into enduring business success.

So what does this collaboration look like? It starts with attendees feeling engaged and challenged throughout the three busy days of sessions and tutorials. Their enthusiasm about the tools we have to offer builds over the course of the week, inspiring them to pass the information they glean up the chain of command once they return to the office. The leadership team is receptive to the new ideas, which are incorporated into the company’s short and long-term strategic plans. From there, the information turns into action, and the ideas presented at the conference reappear in the form of a modernized and more powerful application based on proven functionality. Of course, this process could take months, or even years—but with the partnership in place, these goals CAN and WILL be achieved. We’ll do our part and give it our all during those three days of presentations and demos—but it is up to attendees and their managers to meet us halfway by ensuring that the lessons learned don’t get swallowed up in the daily grind, and that the investment in education leads to innovation and increased efficiency back at the office.

I was discussing this vision with a customer’s Senior Manager who is planning on sending a contingent of software developers to this year’s conference. She made my day when she described the system her company has adopted to maximize the value of the DevPartner Conference: after returning to the office, the team presents a condensed version of what they learned to the staff back at home. Studies have shown that explanation significantly facilitates learning, so this is a great way for attendees to reinforce the skills learned at the conference—while at the same time sharing the information with the rest of the team.

Whether or not you go with this model, you have a little over 6 weeks to prepare your own post-conference plan for success. Let us know how we can partner with you to make it happen!

See you in Birmingham or Chicago.

Cheers!


Performance problem upgrading to Server 2012

By Roger Andrews, Posted on February 28, 2014 at 12:06 pm

When one of our customers recently upgraded a file server from Windows Server 2008 to Server 2012, their customers complained of significantly increased end-of-day processing times—up to three times slower with Server 2012 than the previous system.

The system used terminal services to allow remote administration and running of such tasks as day-end processing. There were no general interactive users. Running the same software on a Windows 8 client system resulted in better performance, all other things being equal (disk, network, CPU, etc.). But a brand new Server 2012 R2 system with just the basic GUI role, performed twice as fast as the Server 2008 system. However, as roles were added, the customer noticed that the RDS role caused the slowdown.

Since Server 2008 R2 was introduced, RDS (Remote Desktop Services, formerly known as Terminal Services) has included a feature called Fairshare CPU Scheduling. With this feature, if more than one user is logged on a system, processing time is limited for a given user based on the number of sessions and their loads (see Remote Desktop Session Host on Microsoft TechNet). This feature is enabled by default and can cause performance problems if more than one user is logged on the system. With Server 2012, two more “fairshare” options were added: Disk Fairshare and Network Fairshare (see What’s New in Remote Desktop Services in Windows Server 2012 on TechNet). These features are enabled by default and can come into play when only one user is logged on. And these options proved to be the cause of the slowdown for our customer. They limited I/O for the single logged-on user (or scheduled task), though the day-end processing was always I/O bound. We were able to remove this bottleneck by either disabling the RDS role or turning off fairshare options.

In summary, if a system is used for file sharing services only (no interactive users), use remote administrative mode and disable the RDS role. If the RDS role must be enabled, consider turning off Disk Fairshare if the server runs disk-intensive software (such as database or I/O-intensive programs), and turn off Network Fairshare if the server has services (such as Microsoft SQL Server or xfServer) to prevent client access from being throttled. For information on turning off Disk Fairshare and Network Fairshare, see Win32 TerminalServiceSetting Class on Microsoft Developer Network (MSDN).

More articles related to this issue:

·         Resource Sharing in Windows Remote Desktop Services
·         Roles, Role Services, and Features


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.

XAML

 

 

 

 

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 https://youtu.be/FqWpMRrSb4w.


Using Synergy .NET in Multi-Threaded Applications

By Steve Ives, Posted on October 10, 2013 at 12:28 pm

There are special considerations that must be taken into account when implementing non thread-aware Synergy .NET code that will execute in a multi-threaded environment. As will be explained later, one such environment is when code executes within an ASP.NET / Internet Information Server (IIS) environment.

The Microsoft .NET environment provides a mechanism to allow the isolation of multiple instances of an application from one another. This mechanism is called Application Domains, and is often referred to as AppDomains. Essentially an AppDomain entirely isolates an instance of some piece of executing code from all other executing instances of that, and any other code, so that these instances cannot interfere with one another in any way. AppDomains also ensure that the failure of any code executing within an AppDomain cannot adversely affect any other executing code.

AppDomains are specifically useful in situations where there may be multiple instances of a piece of code executing within the context of a single process, for example where different execution threads are used to perform multiple concurrent streams of processing (perhaps on behalf of different users) all within a single host process. An example of such an environment is ASP.NET Web applications executing on an IIS Web Server.

Synergy .NET provides specific support for isolating non thread-aware code in AppDomains, and in some situations it can be critical that AppDomains are used in order to have your Synergy .NET code behave as expected in several key areas. Those key areas are channels, static data, common data and global data.

If any of the above items are used in a multi-threaded environment without the use of AppDomains, then they are SHARED between all instances of the code running in the multiple threads. By using an AppDomain, code executing within a given thread can isolate itself from code running in other threads, thus returning to the normal or expected behavior in Synergy environments.

If you are implementing Synergy .NET code that does not make use of multi-threading, and will not execute in a multi-threaded application host then you don’t need to worry about any of this.

If you are implementing multi-threaded Synergy .NET code then you have the option of using AppDomains to isolate parts of your code from other instances if you chose or need to do so.

However if you are implementing non thread-aware Synergy .NET code that will execute in an ASP.NET / IIS environment then you are automatically in a multi-threaded environment and it is critical that you use AppDomains to isolate instances of your application code from each other.

The basic problem is this: ASP.NET and IIS isolate different APPLICATIONS within their own AppDomains, but within an ASP.NET application, multiple (potentially lots of) user “sessions” all execute within the SAME AppDomain. This means that by default there is no isolation of executing code between multiple ASP.NET user sessions, and with Synergy .NET that in turn means that channels, and static, common and global data is shared between those multiple user sessions. As an ASP.NET user session is often considered to correlate to a user process in a regular application, the problem becomes apparent. If one “user” opens a new channel and reads and locks a record, that same channel and record lock are shared with all other users. If one user places a certain value in a common field for use by a routine that is going to be called, that value could be changed by code running for a different user before the first users routine gets called.

Clearly it would be very difficult, if not impossible to build and execute reliable code in this kind of environment. Without support for AppDomains in a multi-threaded environment a Synergy developer would need to:

  • Always use automatic channel number selection.
  • Always close any channels before returning from the routine that opened the channel (no persistent open files)
  • Not use static, common or global data unless the nature of that data is that it contains application wide information that does not change during execution.

While it is possible to write code which adheres to these rules, it would be at the least inconvenient to do so, and because of the way that Synergy code has typically been written in the past, existing code would likely require significant reworking.

The solution to this problem is to have each “users” code isolate its self from other “users” code by loading its self into an AppDomain, and this is relatively easy to do. Specifically in the case of an ASP.NET Web application, code can be written to hook the Session_Start event that signals the beginning of a new user session and create a new AppDomain in which to execute, and hook the Session_End event and execute code to clean up by deleting the AppDomain. There are other possible approaches that may be more appropriate, but the principal is basically the same; have the code isolate its self in an AppDomain before any non-thread aware Synergy .NET code executes.

By isolating non thread-aware Synergy .NET code in an AppDomain in a multi-threaded environment you have essentially the same operating environment that you would expect for any other Synergy code executing in a process, with one notable exception. That exception is that environment variables created with XCALL SETLOG are always applied at the PROCESS level. This means that Synergy .NET code executing in any multi-threaded environment should never rely on the use of XCALL SETLOG unless the value being set is applicable to code executing in all other threads. An example of this might be an environment variable that identifies the fixed path to a data file.

Synergex Professional Services Group is in the process of developing code for a sample ASP.NET Web Application that will demonstrate how to use AppDomains to ensure that code executing in one ASP.NET Session is isolated from other ASP.NET Sessions. We will publish this code in the Synergy/DE CodeExchange soon. I will post another article on this BLOG once the code has been published.


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”>

<Setter.Value>

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

<Label

Content=”Group ID”

IsEnabled=”{Binding Path=Group_idIsEnabled}”>

</Label>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

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”>

<Setter.Value>

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

<TextBox Name=”ctlGroup_Group_id”

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

UpdateSourceTrigger=PropertyChanged,

ValidatesOnDataErrors=True}”

Validation.ErrorTemplate=”{StaticResource validationTemplate}”

MaxLength=”20″

Width=”320″

CharacterCasing=”Upper”

IsEnabled=”{Binding Path=Group_idIsEnabled}”

IsReadOnly=”{Binding Path=Group_idIsReadOnly}”

VerticalAlignment=”Center”

HorizontalAlignment=”Left”

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

<TextBox.Style>

<Style>

<Style.Triggers>

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

<Setter Property=”FocusManager.FocusedElement”

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

</DataTrigger>

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

<Setter Property=”TextBox.Background”>

<Setter.Value>

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

<LinearGradientBrush.GradientStops>

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

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

</LinearGradientBrush.GradientStops>

</LinearGradientBrush>

</Setter.Value>

</Setter>

</DataTrigger>

</Style.Triggers>

</Style>

</TextBox.Style>

</TextBox>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

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;

xmlns:symphonyControls=”clr-namespace:Symphony.Conductor.Controls;assembly=SymphonyConductor”

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}”>

</symphonyControls:FieldControl>

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 http://youtu.be/FqWpMRrSb4w. 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.

 


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 emails 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.

https://community.mcafee.com/community/security/blog/2013/06/07/xp-end-of-life–08-april-2014

https://community.mcafee.com/community/security/blog/2013/06/07/xp-end-of-life–08-april-2014

http://blogs.windows.com/windows/b/springboard/archive/2013/04/08/365-days-remaining-until-xp-end-of-support-the-countdown-begins.aspx

http://blogs.technet.com/b/mspfe/archive/2013/04/29/windows-server-2003-rapidly-approaches-end-of-life-watch-out-for-performance-bottlenecks.aspx

http://www.microsoft.com/en-us/windows/endofsupport.aspx

 

 


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 http://youtu.be/A0eMoLt_8iE.This 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 http://youtu.be/DkoVIEmr3NY 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.


Page 5 of 13« First...34567...10...Last »
Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Tag Cloud Archives