Tomorrow morning I’m heading back home to California having spent the last two weeks in the United Kingdom. The second week was totally chill time; I spent time with family and caught up with some old friends. But the first week was all about work; I spent a few days working with Richard Morris (it’s been WAY too long since that happened) and I can tell you that we worked on some pretty cool stuff. I’m not going to tell you what that is right now, but It’s something that many of you may be able to leverage in the not too distant future, and you’ll be able to read all about it in the coming weeks. For now I wanted to let you know that we found that we needed to add some new features to CodeGen to achieve what we were trying to do, so I am happy to announce that CodeGen 5.1.3 is now available for download.
This is just a brief update on the current status of the PDF API that I have mentioned previously on this forum. During the recent DevPartner Conference in Washington DC I received some really great feedback from several developers already using the API, and some very positive reactions from several others who hope to start working with it in the near future.
During my conference presentation about the API I mentioned that I was considering making the code a little easier to access by moving it out of the Code Exchange and on to GitHub. Well it turns out that was a popular idea too, so I am pleased to announce that I have done just that; you can now obtain the code from its new home at https://github.com/Synergex/SynPSG_PDF. And if any of you DBL developers out there want to get involved in improving and extending the API, we will be happy to consider any pull requests that you send to us.
One cool aspect of a Synergy UI Toolkit program has been list processing. When we introduced the concept of a list load method to populate the list as items were required was a huge step towards decoupling the program logic from the user interface. Because of this separation of concerns it’s actually very easy using the Symphony Framework to load a modern WPF data grid using an existing UI Toolkit list load method.
Our starting point has to be the UI, and that’s being rewritten in XAML. XAML allows data binding between class properties and the column elements of a data grid. We exposes our Synergy data by use of a Symphony Data Object. These data object classes represent your repository based data structures. The fields within your structures are exposed as the properties that the data grid will data-bind to.
Once we have the data grid defined we need to define the hooks between the collection of data we are going to expose to the data grid and the host programs list load method. First we call a generic method that will allow us to signal the required list loading requirements back to the host program. This snippet is going to call a generic method that will then raise the event back to the host:
We are passing the load method name and then various parameters that define the actual data we are going to load and any additional list load method data. Now we can raise the load method request to the host DBL program:
In the host DBL program we need to handle the event so we register an event handler:
The following code snippet dispatches the load request to the existing UI Toolkit load method. There are two formats to the request depending if the list has associated list method data:
So now we need to change the load method. If you have coded your list load method according to the standards laid out in the UI Toolkit manual there should only be a single line of code to change:
The DoingTK test is a flag we have set to indicate if the program is running with the traditional UI Toolkit or our new WPF UI.
We shall be drilling down into the ability to handle list loading during the DevPartner 2016 pre-conference workshop as we all migrate an existing UI Toolkit program to a modern WPF user interface.
We are excited and grateful to celebrate Synergex’s 40th year in business.
We started by delivering applications to local businesses in the Sacramento area 40 years ago today. Shortly after opening our doors, founders Ken Lidster and Mike Morrissey got frustrated with having to rewrite perfectly good applications to take advantage of the latest DEC (Digital Equipment Corporation) hardware and/or operating systems each time DEC came out with a new kit. This inspired them to create DBL (Data Business Language), which could take any version of DEC’s DIBOL language and simply recompile and relink to run on any DEC platform. This dramatically changed our—and ultimately our customers’—direction and put us on the map, as they say.
DBL was the first portable development language within DEC. In the ‘80s, Synergex (then named DISC) also became the first company to make it possible to migrate applications from a proprietary environment to the then emerging Unix/Xenix and MS-DOS systems. In the ‘90s, we enabled migration to Windows; at the turn of the century, to the web, APIs, and RDBMSs (SQL Server, Oracle, ODBC access, etc.); and in the teens, to .NET. Today we provide a migration path to mobile devices.
Forty years ago, very few of us, if any, could have imagined how today’s computing environment would look. Fewer still could have imagined that the applications they were developing would be able to run on all of these emerging platforms—but they can! Last week, I saw a DBL source code file dated 1976 run in .NET and on an Apple iPhone. Again, who could have imagined?!
Since our early shift to providing software development tools to application developers, our commitment to “portability” has never wavered. We have remained steadfast in our mission to deliver software tools and services to help our customers take advantage of current and relevant computing. Our products have been the ultimate “future proofing” to the significant investment customers have made in enterprise solutions.
And while many companies that were well known back in the day are no longer on the scene, we continue to grow and thrive more than ever—thanks in large part to our customers. Many of our ISV customers are the leaders in their respective vertical markets and continue to maintain their top positions and expand their install base. Some of our direct end users are household names with north of $100 billion in annual sales, who leverage our tools to help them prosper. Without their support and partnership, I wouldn’t be writing this. So here’s a big shout out to all of our customers, with the biggest thanks there is.
Lastly, a company doesn’t grow and thrive without the dedication and hard work of its employees—both past and current. We have been—and continue to be—blessed to have very talented and driven people contribute to our success these past 40 years. Several, like myself, have been here for the lion’s share of our existence. But we also have many new employees who represent the future—and the next 40+ years of Synergex. Just as 40 years ago we couldn’t imagine what our industry would look like today, it’s impossible to envision what it will be like 40 years from now. Regardless, I feel very confident that Synergex will be here for our customers and their future generations, supporting whatever future computing environments come along.
It’s the tried and trusted way to get the users attention. At the slighting hint of an issue with their data entry you put up a big dialog box complete with warning icons and meaningful information.
We’ve all done it, and many programs we write today may still do it. Writing code using the Synergy UI Toolkit its common practice to write a change method to perform field level validation. When the user has changed the data and left the field – either by tabbing to the next or clicking the “save my soul” button – the change method executes and validates the entry. It is here were we stop the user in their tracks. How dare they give us invalid data – don’t they know what they should have entered? It’s an ever so regimented approach. The user must acknowledge their mistake by politely pressing the “OK” button before we allow them to continue. Users are usually not OK with this interruption to their daily schedule so there must be a nicer way to say “hey there, this data is not quite as I need it, fancy taking a look before we try to commit it to the database and get firm with you and tell you how bad you are doing at data entry?”
When migrating to a new Windows Presentation Foundation UI we can do things a little different and guide the user through the process of entering the correct data we need to complete a form or window. We will still use the same change method validation logic however as there is no reason to change what we know works.
When using the Symphony Framework you create Symphony Data Objects – these classes represent your repository based data structures. The fields within your structures are exposed as properties that the UI will data-bind to. These data objects are a little bit cleverer that just a collection of properties. Based on the attributes in the repository it knows what fields have change methods associated with them. Because of this the data object can raise an event that we can listen for – an event that says “this field needs validation by means of this named change method”. Here is a snippet of code registering the event handler:
The event handler simply raises the required “change method” event back to the host DBL program;
Back in the DBL program we can now listen for the change method events. Here is the event handler being registered:
Remember, we are now back in the host DBL code so we can now dispatch to the actual change methods registered against the field. This is a code snippet and not the complete event handler code:
We are calling into the original change method and passing through the required structure data and method data. Inside the change method we will have code that validate the entry and then, as this snippet shows, we can perform the error reporting:
If the code is running as a UI Toolkit program the normal message box dialog is used to display the message. However, when running with the new WPF UI the code provides the required error information against the field. No message boxes are displayed. To the user they will see:
The edit control background is coloured to indicate an issue with the data and the tooltip gives full details of the problem. When the user has entered valid data, the field reverts back to the standard renditions:
We shall be exploring the ability to handle field change method processing during the DevPartner 2016 pre-conference workshop as we all migrate an existing UI Toolkit program to a modern WPF user interface.
Menu processing is a fundamental requirement in any UI Toolkit program. Without menu columns and entries your program would not function. You also signal menu events from toolbars, and buttons placed on windows and lists. Once a menu entry of any sort is fired, even if it’s signalled from within the DBL code, there is usually a using statement that dispatches to the required segment of logic. When configuring a new Windows Presentation Foundation UI this technique is still valid.
The Symphony Framework UI Toolkit assists the developer to bridge the connection between the DBL host program and the commands associated with menu bars, toolbar, and buttons – basically any WPF control that can bind to a command, and that includes selecting an item within a data grid!
Before we head into how the Symphony Framework UI Toolkit helps let’s first look at some simple UI Toolkit script and code snippets. Firstly we can create menu entries in scripts:
Here we have a menu column called “mfile” with an entry called “f_new”. The important element is the entry name “f_new” as this is the menu signal name that is used within the DBL code. You can create toolbars in code that will signal a menu event, for example:
Here we have the same menu event name of “f_new” being signalled when the toolbar button is selected. We can also add buttons to tab containers;
Windows and lists can also have buttons added to them both in scrip and in code;
If we need to enable or disable the “f_new” capability within the UI Toolkit application we need to do this for all instances, for example;
The Symphony Framework UI Toolkit removes the verbosity of this structure of programming while retaining the same logical concept. Using the Symphony.UIToolkit.Menu.MenuController class allows you to create a command;
Now we have the command we can bind it to any WPF control that accepts a command binding. So for a menu;
We can utilise the same command on, for example, an Infragistics ribbon control;
Using a regular tool bar;
And of course as a regular button on an input form or data grid view;
In the host DBL code we can now simplify the control of the commands. By enabling the single command it changes the executable status of the all UI controls that it is bound to;
When the command is executed the toolkit menu entry is signalled to the host program. We need to define an event handler;
This is a code snippet and not the complete event handler code:
This code is setting up the required menu entry name and then calling into the host DBL code to process the menu select. In the host program we need to ensure that we dispatch to the menu processing code segment. In this example the original toolkit code was processing an input form. We continue to process the input window using the i_input() routine if the toolkit is still the active environment. If we are running using the new WPF UI then we simple process the menu event;
We shall be covering menu, toolbar and command processing during the DevPartner 2016 pre-conference workshop as we all migrate an existing UI Toolkit program to a modern WPF user interface.
It was very exciting to learn at Build this week that Microsoft will now be offering Visual Studio (VS) as a development tool to build anything to deploy anywhere—from Linux to Apple to Android, you name it! As Steve Ives referenced in his recent blog post, all of the Xamarin tools that we’ve been leveraging are now included with VS.
The really cool thing about all of this is that Microsoft’s direction is in perfect alignment with ours. At our Summit meeting at the end of last year—a gathering of Synergex customers who provide input on Synergex’s technology roadmap—we received overwhelmingly positive feedback on our proposal to include the ability to use traditional Synergy within Visual Studio.
More and more of our customers are adopting Synergy .NET while still maintaining and developing in traditional Synergy, leading them to work with two separate development IDEs: Workbench for traditional Synergy and VS for Synergy .NET. We are happy to say that this will all change with the release of Synergy/DE 10.3.3, pegged for OUR conference in May. The 10.3.3 release will allow developers to use VS for both traditional and Synergy .NET—the post-conference workshop is even dedicated to this topic! I’m even thinking that this new functionality might inspire even more developers to play/experiment with Synergy .NET once they are using VS as their single IDE.
Synergex has always been committed to helping companies leverage their existing investments to stay competitive and current. This latest announcement from Microsoft really echoes that sentiment. After this week, reaching for the stars is now easier than ever!
One of the big news items from today’s Keynote at the Microsoft Build conference is that the Xamarin tools, which allow .NET developers to create fully native apps for the iOS, Android and Windows Universal platforms with a single code base, will in future be bundled for free with Visual Studio. Microsoft purchased Xamarin in February 2016 and since then a lot of developers have been waiting with baited breath to find out what would change, and now we know. Exciting news if you want to develop mobile applications.
Today, amongst many other things, Microsoft announced the release of Visual Studio 2015 Update 2. We wanted to let you know that if you are doing Synergy .NET development with the current Synergy 10.3.2 beta version then it’s OK to apply Update 2. But if you’re running the 10.3.1 release of Synergy (or an earlier version) you should not install Update 2 just yet. We are currently finalizing and will soon release a hotfix for Synergy 10.3.1 to that will add support for Visual Studio 2015 Update 2, but for now you should stick with Update 1.
Last year I announced that we had created a new PDF API and made it available via the CodeExchange in the Synergy/DE Resource Center. Now I am pleased to announce that we have made some enhancements to the original API, namely by adding the ability to:
- View existing PDF documents (Windows only).
- Print existing PDF documents (Windows only).
- Draw circles.
- Draw pie charts.
- Draw bar charts (with a single or multiple data series).
Here’s an example of a pie chart that was drawn with the new API:
Here’s an example of a bar chart:
And here’s an example of a multi-series bar chart:
It’s early days for the support of charts, and I plan to make several additional enhancements as time permits, but I wanted to make the work that has been done so far out into the wild, and hopefully get some feedback to help me decide what else needs to be done.
If you’re interested in learning how to use the PDF API then I’ll be presenting a session that will teach you all about it at our up-coming DevPartner conference in May. So if you haven’t already done so, head on over to http://conference.synergex.com to reserve your spot at the conference now.
I’m sometimes sceptical when somebody covers a song I know and love as I’m worried that their version may not bring with it the true spirit of the original track. If it’s not done right it just won’t be pleasing to the ear, and music should always invoke passion. When customers ask us to demonstrate how to put a new User Interface over an existing program I’m always conscious that our “cover” needs to retain the proven logic of the original program while offering the user a new and pleasing, easy to use and navigate, user experience.
In recent weeks I’ve been developing the Symphony UI Toolkit, which as the name suggests, helps you to migrate your Traditional Synergy UI Toolkit programs to a modern Windows Presentation Foundation (WPF) based UI. This new member to the Symphony ensemble provides a number of simple techniques for connecting between the WPF UI and the existing “event” driven DBL code.
One recent engagement where I utilise the whole Symphony Framework, including the new Symphony UI Toolkit, was to add a modern UI to an existing UI Toolkit program. The basic solution was to write the new UI in Synergy .NET using XAML for the UI components. Then host this in the existing Toolkit program using the DOTNET API. We started off with:
The program presented a list of items from which the user could select from. Other than the slightly dated look and feel the main problem with the application was that the user was restricted to seeing only the information on a single tab page at a time. The brief for the new UI was simple – make the pages dock-able.
Utilizing a number of core features within the Infragistics UI control set I was able to retain all the logic from the original program and bring a fresh new UI to the user:
Now as the user navigated the main list of items, while the docked panels display the relevant information. The grid provided the required filtering and grouping capabilities and selecting an item changed the fields on the input panels to edit mode so changes and additions could be made.
The Microsoft styled ribbon control replaced the traditional menu columns and button toolbar. Additional options were made available within an Outlook style navigation bar – which can be hidden with a single click.
The original program code was modified in a way that we can swap between running the traditional UI Toolkit UI and the new WPF UI by changing a single setting in the synergy.ini configuration file:
Although targeting the UI Toolkit the steps involved in migrating to a new WPF UI with the Symphony Framework will work just as well with almost any style of DBL program, and you can try it for yourself at DevPartner 2016. Join me in the recording studio for the Monday pre-conference workshop where together we’ll make a great new cover version of an old Toolkit program. The day will start relaxed as you write code to handle menu, toolbar and button commands. Then we’ll up the tempo and you’ll code event handlers to execute list load methods. Then we’ll jazz things up a little handling change methods and field validation. By the end of the day we’ll have a number 1 hit on our laptops.
It seems like since we moved CodeGen from CodePlex to GitHub there has been some confusion about how to download the latest version. The latest version will always be available at:
We have just released a CodeGen update that includes a fix for a problem that was discovered recently related to the processing of enumerated fields. If your repository includes enumerated fields and you use the field selection loop token <SELECTION_VALUE> (or the Symphony Framework custom token <SYMPHONY_SELECTION_VALUE>) then we recommend that you update to the new version and re-generate your code. As a reminder CodeGen recently moved to GitHub, you can find the new release at https://github.com/Synergex/CodeGen/releases.
Today we are announcing that we have moved the open source CodeGen project from it’s former home on CodePlex to a new home on GitHub. We made the decision to do this for several reasons, not least of which is the fact that GitHub has effectively become the de-facto standard place for hosting open source projects. Even Microsoft, who built and operate the CodePlex site using their own Team Foundation Server source control technologies seem to have lost interest in it; in the last 18 months or so they have moved pretty much all of their own considerable number of open source projects to GitHub also! GIT also has several very nice features over and above what TFS has to offer, and also has the benefit of being very considerably faster to use. Related to the move is a new version (CodeGen 5.1.1), but the only changes in the new version are related from the move from CodePlex to GitHub; there is no new functionality in the new release over the 5.1.0 version that was released a few days ago.
If you don’t already have one we encourage you to create a GitHub account and once logged in to “watch” CodeGen. If you wish to receive notifications about new CodeGen releases you can also subscribe to the CodeGen Releases Atom feed. CodeGen is still distributed under the terms of the New BSD License. For the time being we plan to leave the CodePlex environment intact, but no new changes will be checked in there and no new releases will be published there.
Here are a few useful GitHub URLs related to our new home:
|Download latest version||https://github.com/Synergex/CodeGen/releases/latest|
|Releases Atom feed||https://github.com/Synergex/CodeGen/releases.atom|
Just a quick note to announce that we have today released CodeGen 5.1. This release has but one new feature, but it does allow me to solve a challenging problem that I faced while working on a customer project recently. I have dubbed this new feature conditional processing blocks. Essentially it is the ability to conditionally include (or exclude) parts of a template file based on the presence or absence of identifiers that can be declared on the command line. It allows you to achieve the same kind of results that you would when using .DEFINE, .IFDEF and .IFNDEF in DBL source code, but within template files. For example a developer could include code like this in a template file:
The developer would then have the ability to choose whether to include or exclude the code that assigns the I/O hooks object to the channel that was opened at the time that they generate the code. By default the I/O hooks code would not be included; if it was needed the developer would define the ATTACH_IO_HOOKS identifier as they generate the code. They would do this by using a new –define command line option:
codegen –s EMPLOYEE –t FILE_IO_CLASS –r –define ATTACH_IO_HOOKS
This may seem like a very simple change, and it is, but my mind is now racing thinking about all of the new possibilities it opens up.