Open Menu

Synergex Blog


The .NET Rollercoaster

By Richard Morris, Posted on November 24, 2010 at 1:28 pm

Sometimes my job feels like I’m on a rollercoaster with some great highs and some scary lows, and the adrenaline rushes between the two. Version 9.5, complete with the Visual Studio integration with Synergy, was officially released yesterday. I’m sure I was not the first one, but I was straight to the resource centre at www.synergex.com to download and install 9.5. The installation went without issue and we were ready to begin to build our CRM application.

The first task was to rebuild our existing Synergy routines using the Synergy 9.5 DBL compiler. This new version has tightened things up even more and the compiler found another subscripting error which was duly fixed! Things were looking great – the rollercoaster car was slowly making its assent.

The next step was to build our Visual Studio projects and run the new CRM application. The builds completed and the car was teetering on the brink. But what goes up must come down. With that stomach in the mouth feeling the car came spiralling down from the dizzy heights. Our CRM didn’t run quite as we’d hoped. Now don’t get me wrong. I’m extremely impressed with the release of 9.5 and the integration with Visual Studio. Just the ability to build code written when Bill Gates was a lad in this environment is testimony to the strength of Synergy. But this is a brand new release and I’m pushing it to the limit. This is no “Hello World” development!

Now the customer wants a new CRM, and I’m determined to complete the job using Synergy. And so a new plan was hatched. Why can’t we use Synergy/DE and Workbench to build the program to host our new UI? We can use the .NET API to achieve this, and we know all the existing routines work because they have been executing the code for years. So straight away we have half of the application in Synergy, written and working. Given that the problems we were having with the Visual Studio side of 9.5 centred on arrayed fields, changes that have been made to the way error trapping works, and the debugger, why not build our WPF UI using Synergy. And this side of the Visual Studio integration worked for us all day without issue. Building simple class files to expose our Synergy data as .NET types was a breeze with the code snippets available. Some of this code could, I guess, be code generated, but to be honest generating code can strangle the flair of the developer. Plus we only wanted to expose selected fields and manipulate the format of the data to suit our needs.

We soon had our data classes built and the application was returning data ready to expose to our new WPF UI. And this is our task for tomorrow. The car is well and truly back on track and heading for the exciting twisty section of the ride. And I’m still only programming in Synergy. There is not a single line of C# or VB.NET!

So, should you wait before you try 9.5? Certainly not! Download it, install it, and start to build not only your code but your dreams of that new slick looking application – and all in Synergy. I’ll post the results of all our hard work at the end of the week. Please keep all hands and feet within the car and hold on tight to the hand rail. You’re going to love the ride!


.NET is a blast

By Richard Morris, Posted on November 23, 2010 at 3:19 pm

One great aspect about my job is not only helping people utilise Synergy to the full, but to see the results of their hard work. And there is no better place to do this than “at the coal face”. Today’s coal face is, of course, on the shop floor at White Knight laundry. I was given a guided tour after lunch to see just how the Synergy system tracks items through the process.

The washing machines are huge, several feet taller than me. I shudder to think just how many pairs of socks you can wash within one of them, and they have several, all lined up together. It’s no wonder they have to tag every single item. Once items are cleaned they are dried in large driers and then the cool automation happens. Sheets are taken out of the dryers and each is laid out in turn at one end of a machine. If you are quick enough and sprint around to the other side of these large machines out pop a beautifully pressed and folded sheet. The shirt press is a blast, literally. It’s a two stage operation. Firstly the collar and cuffs are placed onto a machine and pressed. Then the shirt is placed over a frame, then it’s whisked off and steam blasted through it, and out comes a perfectly pressed shirt fit for a king.

And so to our CRM development. Our first task was to build the White Knight core routines into a native .NET assembly, which is the equivalent of an executable library. This task was achieved within a couple of hours. After all, it’s the same Synergy Language just a new compiler. The current system runs under Synergy version 8.3 and this code, I would say, hasn’t changed much since version 5.9 days. It’s testament to the power of Synergy to be able to take this code and build it under a brand spanking new development environment called Visual Studio 2010! To successfully build the new assembly required a few code changes. The compiler caught parameter mismatch declarations and some over subscripting. All the modifications we made improved the stability of the code.

We are now ready to begin to integrate our tried and tested logic with our new WPF UI. But there is a little more work to do first. Our data is a little shy and we need to gently coax it from the dark depths of our SDBMS files. Remember, some of this data was written away to the file a long time ago and those little single alpha character chaps that store our Y or N values work just fine in Synergy land, but for WPF we need to coerce these values to native types. So we are writing some very simple classes that take our Synergy records and expose only the fields our UI will be interested in as native .NET types.

Now we are building the WPF interface and binding to our new Synergy classes, exposing our existing Synergy data…


Taking .NET to the cleaners

By Richard Morris, Posted on November 22, 2010 at 2:23 pm

Ding dong, “Laundry service”! Now you could be mistaken for thinking that I’m staying in a rather nice hotel, being called upon by the maid for my dirty laundry. Not so, I’m afraid, I’ll be taking my dirty ‘smalls’ home with me. But for one of our customers, this is their calling card. The customer is White Knight, based near London and their business is laundry, run by Synergy.

It’s true. People and many of them are well known celebrities, have their laundry collected every Monday and returned within a few days, cleaned dried and perfectly ironed. Some ten thousand “items” pass through the machines at this site and this is a small site. Their other sites handle in excess of two hundred thousand articles every week.

To manage this workload across all sites is a suite of Synergy programs running on a Linux machine. Traditional character based systems handle all aspects of the process from collection, cleaning through to delivery of the right items to the correct customers.

But things don’t always go right. So when the customers call in and say “you’ve washed the spots off my favourite pair of shorts” it all needs to be recorded and processed. This calls for a CRM (Customer Relations Management) system. And here is where I enter the story. White Knight has invited me down to assist them to begin to write a fully functional CRM system in Synergy. They want a Microsoft Windows desktop application with all the bells and whistles with access to new and existing Synergy data and logic. Easy!

So today we hatched a plan. Graham from White Knight was fully prepared for my visit with a functional specification, data layouts and design utilising xfServerPlus. “But for a desktop application?” I asked. “Why are we not using WPF (Windows Presentation Foundation) and .NET?” Because I’m not strong with C#, I know enough to do my web site!” Graham replied. Well, given the imminent release of Synergy v9.5 and the integration of Synergy Language within Microsoft Visual Studio 2010 it would be a perfect candidate. We’ve created our Visual Studio projects and begun to define our WPF User Interface in XAML. Our existing Synergy routines are being imported into a new class library project and we are crafting Synergy classes to facilitate the communication between our application elements. For those of you at SPC 2010 you’ll recognise this as the Model-View-ViewModel pattern!

And how did we do? Well I’ll update my blog over the next few days of how well we do, writing our first Synergy for .Net application…..


Dig into Synergy/DE 9.5 – Using CodeExchange

By William Hawkins, Posted on November 19, 2010 at 12:46 pm

Like many of you, I’ve been waiting with bated breath for the release of Synergy/DE 9.5, and the general availability of Synergy .NET. The development team has been working on this project for a few years (I’m sure it seems like longer for them). But it wasn’t until the beta release earlier this year, that it became something with which you could actually start to write code that really did something useful. Those of you who were at the SPC a few weeks ago had an opportunity to use Synergy/DE 9.5 to develop a WPF application that used Synergy for all the (non-XAML) code in Visual Studio 2010.

As part of the beta testing effort, I’ve been using and updating code that has been submitted to the CodeExchange, and I thought I’d share what I did. Hopefully you can leverage the modifications that were done to the CodeExchange items to help with a possible migration to the .NET environment.

In order to make my life easier, I created a folder C:\Development\CodeExchange and deposited all of the CodeExchange submissions that were created by Synergy PSG, into subfolders.

Phase 1 Test the code in traditional Synergy 9.5.

As I knew I’d be doing a lot of test builds, I wanted to use the project build system built into Workbench (in Synergy/DE 9.3). So I created an empty workspace, and added all the Workbench projects that were in the subfolders. For those projects that didn’t have a Workbench projects, I created one, and for the few projects that didn’t have a mainline program, I created one of those too. Most of the time spent in this phase was in setting the Workbench build environment. As you would expect, the code didn’t require much (if any) modification.

Phase 2 Test the code in Synergy .NET 9.5.

When taking the CodeExchange submissions and building them in Visual Studio, it turned out to relatively easy. In order not to “pollute” the standard CodeExchange folders with Visual Studio “stuff”, I decided to create a separate folder for Visual Studio project. This was C:\Development\CodeExchangeVS, and under this folder is a subfolder for each submission – just like the Workbench folders. Inside these subfolders are a Visual Studio solution and a Synergy project. The Synergy project contains references to the code in the Workbench folders, so that I can use the same code in both places. If you just add a source code file to a Visual Studio project, what you’re really doing is copying the file to the project folder, but all Add Reference does is point the project to the appropriate source file. Now that I have a Visual Studio project, it’s just a matter of hitting the F6 button to build my application. If only it were that simple…..

When building the CodeExchange code in Visual Studio, the code falls into a number of different categories;

1) Requires no/minimal changes

2) Uses features (functions/subroutines) that are not supported

3) Needs recoding

4) Uses features (APIs) that are not supported

Again, most of the code fell into the first category, as it had already compiled using the traditional Synergy compiler. One thing that fell into the “minimal changes” category was the introduction of a logical to point to an include folder (usually the same folder as the source). As Visual Studio was using sources from a different folder, we could no longer rely upon the include file being in the “current folder”. For the purposes of CodeExchange sources, wherever a logical is required to access an include file, the source will use INC:

Also, there was very little code that required recoding – this was almost exclusively required by the use of %DLL_CALL(), which needed to be changed to %DLL_NETCALL(). The coding change was relatively straightforward. (See example below.)

.ifdef DBLNET

begin

argArray = new object[2]

argArray[1] = (object)^addr(spec)

argArray[2] = (object)^addr(WIN32_FIND_DATA)

srch_hdl = %dll_netcall(dll, DLL_TYPE_WINAPI, ‘FindFirstFileA’, argArray)

end

.else ;DBLNET

srch_hdl = %dll_call(dll, DLL_TYPE_WINAPI, “FindFirstFileA”, ^addr(spec), ^addr(WIN32_FIND_DATA))

.endc ;DBLNET

The bulk of the changes needed were mostly to deal with unsupported or not yet implemented features. I first started this project in Feb/Mar 2010, and as time progressed, the number of issues grew significantly smaller as the Synergy development team implemented features omitted from the early betas. At the time of writing, the unsupported features that got caught by the compiler are the use of HTTP_SERVER, %SS_FATAL() and W_CAPTION(). Another problem feature is the use of UI Toolkit. While there is a version of UI Toolkit that you can use when you build using Visual Studio, it’s not a complete implementation. The UI Toolkit provided with Synergy .NET is primarily aimed at allowing UI Toolkit code to be used with xfNetLink .NET and/or .NET interop projects – which are projects that do not use UI Toolkit for the User Interface. If you actually run the application and call a UI-related Toolkit routine, a runtime error will be thrown. For all the projects that used UI Toolkit, I added a try-catch around the entire application, so that I can catch any errors thrown by UI Toolkit. From a CodeExchange perspective, use of UI Toolkit is the main item that falls into the fourth category. The RCB API is another example of an unsupported feature in Synergy .NET.

One difference between traditional Synergy and Synergy .NET, is that there is no “stop message” dialog. “Hurrah!” I hear a lot of you say. Me too. However, with the CodeExchange submissions, most of the test programs are console applications, and now that there’s no stop message, when they complete, the application goes away too. This doesn’t give you much time to read the screen. So I wrote myself a little StopMessage routine, and added it to every application that needed it. As it turns out, this change was by far the largest change that I had to do.

Along the way, we’ve also enhanced some of the submissions; for example, the StringUtil submission is now more functionally rich, and we also added some new submissions (e.g., isamBenchmarks, GetDirFiles, memProc, POP3mail and SelectExample). There is also a new submission CodeExchangeVS which contains all the submissions below, plus the Workbench workspace with all the Workbench projects and all the Visual Studio solutions.

Here are the CodeExchange submissions that are included in the CodeExchangeVS download;

addSourceControl, ASCIIEncoding, axlsort, Base64, Base64_convert, BatchFileConversion, COPY_HANDLE, creditCard, DateTime, DTKproto, dtk_i_enable_set, dtk_list_multi_select, FileLocks, FindNPchars, FixData, GetDirFiles, GetWindowSize, HTTPexample, HTTPqueryString, iConvert, IsamBenchmarks, isHoliday, ismKey, ismSts, lct_lmf, LicensingToolkitExample, ll_accept, memProc, PartialMatch, POP3mail, Registry, RemoteServer, rfa_hex, rpschk, rpssql, rpsxdl, rpsxml, SelectExample, SMTPmail, SocketExamples, StringUtil, synckodbc, SynPsg.Rps, UpsTrack, url_encode, uspsWebService, WinDir, xfnl_synergy, xfplini, xfpllog, xfspism2xml.

Also, one final change. At the request of Synergy/DE Developer Support, each submission includes all the code required to rebuild the application. Previously, some CodeExchange submissions required you to download other CodeExchange submissions.

If you’re using any of the CodeExchange items above, I would recommend that you download the updated version. Synergex PSG is constantly looking for new opportunities to enhance the CodeExchange code submissions, so if you have any suggestions for new items, please let us know.

A Synergy/DE 9.5 RC (release candidate) is available now, and the general release should be available soon.


RSS

Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives