Open Menu

Synergex Blog


Drilling for Data

By Richard Morris, Posted on April 20, 2016 at 5:44 am

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:

d1

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:

d2

In the host DBL program we need to handle the event so we register an event handler:

d3

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:

d4

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:

d5

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.


Synergex Celebrates 40th Anniversary

By William Mooney, Posted on April 15, 2016 at 10:45 am

20160414-banner5
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.


STOP! Validation Alert

By Richard Morris, Posted on April 12, 2016 at 12:00 pm

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.

c1

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:

c2

The event handler simply raises the required “change method” event back to the host DBL program;

c3

Back in the DBL program we can now listen for the change method events. Here is the event handler being registered:

c4

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:

c5

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:

c6

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:

c7

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:

c8

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.

 


What’s on the menu today?

By Richard Morris, Posted on April 6, 2016 at 5:51 am

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:

m1

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:

m2

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;

m3

Windows and lists can also have buttons added to them both in scrip and in code;

m4 m5

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;

m6

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;

m7

Now we have the command we can bind it to any WPF control that accepts a command binding. So for a menu;

m8

We can utilise the same command on, for example, an Infragistics ribbon control;

m9

Using a regular tool bar;

m10

And of course as a regular button on an input form or data grid view;

m11

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;

m12

When the command is executed the toolkit menu entry is signalled to the host program. We need to define an event handler;

m13

This is a code snippet and not the complete event handler code:

m14

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;

m15

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.

 


The stars have aligned—Microsoft’s plans now synchronize with Synergex’s founding principle of portability

By William Mooney, Posted on April 1, 2016 at 3:31 pm

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!

build

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