Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


CodeGen Goes Open Source

By Steve Ives, Posted on May 22, 2012 at 9:45 am

Steve Ives

For several years now I have been developing a tool called CodeGen. As you may have already guessed from the name, it’s a code generator! What’s a code generator? It’s a tool that generates code … sounds useful, right?

Well it is useful, in many different situations. Not all situations of course. If a code generator could generate ANY piece of source code that you might need then we wouldn’t need programmers any more … so why would a programmer write such a tool?

OK I jest a little. Believe me, if it were possible to write such a tool then I would have done it, and I’d have made a lot of money from it, and I probably wouldn’t be sitting here writing this BLOG right now 🙂 No, of course it’s not possible to write a tool that can generate ANY piece of source code, but it absolutely is possible to create a tool that can generate useful code to address a wide variety of different requirements, and that’s what CodeGen does.

So just what is CodeGen? Well, I generally describe it as a “template-driven” code generator. What that means is that you start with a template file that defines the general “rules” for the code that is to be created, and you combine the information from that template file with some meta-data in order to produce the final code. So now the question is where does the meta-data come from? Well, when using CodeGen, in most cases it comes from a Synergy repository.

A repository database is an extremely rich source of meta-data relating to the data structures that are used within your applications. The applications that we write totally revolve around data, they create data, update data, and analyze and present data. So having a repository which completely describes not only the data structures that your application uses, but also a huge amount of additional information about HOW that data is represented and to processed, and armed with an API (ddlib) which allows programmatic access to that meta-data, a programmer can create software that “does things” based on that information. That’s what CodeGen does.

By the way, don’t fret it if you don’t already use Repository … that’s easy to address.

I have no intention of “rambling on” about what CodeGen is and how it works, because that information is all available elsewhere. CodeGen has been in use for several years, I use it extensively, and I have used it to deliver real value to several customers also. In fact in the past, that was the model. CodeGen was a tool developed by Synergex Professional Services Group, and it was available for us to use during consulting engagements. If we used it during such an engagement then that customer got to continue to use the tool, and many have done so.

The real point of writing this post is to announce, with great delight, “that times are a changing”. We’ve decided to take a different tack, and make CodeGen available to a wider audience; a MUCH wider audience. I am delighted to announce that CodeGen is now an Open Source product, and is published for the world to download and use. The project is hosted on CodePlex (Microsoft’s Open Source hosting platform) and you can view the CodeGen project home page at https://codegen.codeplex.com.

So just what does this mean? Well, it means that CodeGen is now available for you to download and use, and I hope that lots of you do just that. CodeGen is now primarily developed with Synergy .NET in Visual Studio, and if you want to use it you have two choices:

  1. Download the pre-built distribution (a Windows Installer setup program).
  2. Download the source code package and build it yourself.

The binary distribution is built with the latest version of Synergy.NET (9.5.3b), so you’ll need that version of Synergy to use it. If you’re working with an older version of Synergy then you’ll need to build CodeGen from source code, but you’ll still need a pretty recent version of Synergy/DE.

Even though the main development environment for CodeGen is now Synergy .NET, it wasn’t always that way. CodeGen started out life as a regular “Traditional Synergy” application, and it still works just fine that way. What that means is that CodeGen is equally at home under Synergy .NET or Traditional Synergy on Windows, Unix, Linux or OpenVMS, and the source code download includes scripts to build CodeGen on all of these platforms.

If you are currently attending the Synergex DevPartner Conference in Chicago, IL then you’re going to hear more about CodeGen during the conference today, and on Tuesday afternoon there will be a hands-on tutorial available to help you get real experience working with it. And if you’re attending the conference in York, England in June then don’t fret, you’ll get the same opportunity. But if you’re not attending either conference (it’s not too late to sign up for York) then you’re definitely missing out on some great information about CodeGen, and a BUNCH of other cool stuff!

But just because you’re not attending the conference doesn’t mean that you can’t use CodeGen. Head on over to https://codegen.codeplex.com to get started right now. And please, even if you don’t use CodeGen right now, at least “follow” the CodePlex project so that you’ll be kept up to date with news about the product.

By the way, to my best of my knowledge this is the first time that a “DIBOL” (Synergy) application has been published as an open source project, and I’m pretty stoked about that. BUT … there’s more! There’s another open source Synergy project about to “hit the streets” … and it utilizes CodeGen … but I’ll leave it up to my friend and colleague Richard Morris to tell you all about that!


Optimizing your Visual Studio 2010 Experience

By Steve Ives, Posted on June 22, 2011 at 3:52 pm

Steve Ives

Visual Studio 2010 is one of the best IDE’s I have ever seen and worked with, and provides, out of the box, a truly impressive array of tools to make developers lives easier and more productive. But, as good as it already is, there is still room for improvement.

Luckily Microsoft has provided an extensible platform and an easy way for people who develop extensions to be able to publish those extensions to developers. Check out the “Extension Manager” utility that you will find on the Tools menu.

emThe extension manager, as suggested by its name, provides a simple UI which allows you to locate, download and install all kinds of Visual Studio extensions. The actual extensions are hosted on-line at a web site called the Visual Studio Gallery. Some extensions are written by Microsoft, some by third-parties. Some provide additional functionality throughout Visual Studio, while some are specific to a particular language. Some add new project or item templates to Visual Studio, while others add complex capabilities in a range of scenarios.

Go take a look, there are a lot of extensions to choose from. If you’re looking for recommendations then personally I think that there are two extensions that no Visual Studio 2010 developer should be without … apart from the Synergy Language Integration for Visual Studio extension of course. You’ll find these extensions in the gallery, and if you sort the list by “Highest Ranked” then they should be close to the top of the list … they are VERY popular! My favorite extensions are both published by Microsoft, and both are free. They are called:

· Productivity Power Tools

· PowerCommands for Visual Studio 2010

I won’t even attempt to go into detail about what these extensions do, because the list of enhancements is a long one. You can click on the hyperlinks above and read all about them in the gallery. Suffice it to say that if for some reason I wind up working on a system other than my own laptop, and these extensions are not installed, I miss them both terribly!


Free Stuff!

By William Hawkins, Posted on March 14, 2011 at 2:46 pm

Avatar

It’s a rare occasion where anything is truely free. Most of the time it’s simply a way for a marketing company to obtain information about you, so they can provide (or bombard) you with information about products that you have no interest in purchasing. However, there are some occasions when “free” really does mean that there’s no additional cost. The Synergex CodeExchange is (IMHO) one of those gems.
In may last blog, I discussed the process of validating a large number of the CodeExchange submissions with Synergy 9.5 and Synergy for .Net. In this blog, I want to highlight a couple of new submissions that you may find useful.

SynArrayList – this submission contains a couple of subroutines that allow you to sort an ArrayList in Synergy, either using a bubble sort or dynamic memory/qsort. You probably won’t need to use both methods of sorting, but they provide code examples to allow you to create custom sort routines of your own. This submission also contains an example of extending the ArrayList class, and creating a new class that processes Synergy alpha types natively.  This allows you to avoid the requirement to box/unbox your alpha variables as you process a collection.  Of course, the underlying arraylist still requires object types, but you don’t have to be concerned about that. And it has sort() and reverse() methods and some other ArrayList method that are part of the ArrayList class in .NET

SourceTree – this submission builds a utility that will parse your source code, and generate a data file that records the subroutine/functions in your application that call other subroutines/functions.  This allows you to create documentation on where routines are used in your application.  It can also be used to generate a list of routines called by a particular subroutine/function/mainline and all the routines that are called by those routines.

I’m also working on some other CodeExchange submissions – examples include a file I/O class and a utlity to create the xfNetLink attributes that can decorate your code.  Watch this space!!!


The .NET Rollercoaster

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

Avatar

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!


Dig into Synergy/DE 9.5 – Using CodeExchange

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

Avatar

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.


Visual Studio 2008 SP1 Hangs After Office Upgrade

By Steve Ives, Posted on July 22, 2010 at 5:55 pm

Steve Ives

Just incase you run into the same issue…

This week I had to revert back to using Visual Studio 2008 while working on a customer project, and I pretty quickly found that I had a problem. I was working on an ASP.NET web project, and found that each time I opened a web page for editing, Visual Studio would appear to hang. Clicking anywhere on the Visual Studio window resulted in the ubiquitous Windows “beep” sound.

On researching the problem in the “Universal Documentation System” (Google) I quickly found that I was not alone in my frustrations … in fact it seems like this is a common issue right now.

Turns out that the problem is related to the fact that I recently updated from Office 2007 to Office 2010. I guess Visual Studio 2008 uses some components from Office 2007 when editing HTML and ASPX pages, and I guess that component got screwed up by the Office 2010 upgrade. If you encounter this problem you will likely find that when Visual Studio 2008 hangs it has started a SETUP.EXE process, but that process never seems to complete. Apparently it’s attempting to do a repair of the “Microsoft Visual Studio Web Authoring Component”, but for some reason can’t.

The solution seems to be to manually run the setup program and select “Repair”. On my system the setup program was C:Program Files (x86)Common Filesmicrosoft sharedOFFICE12Office Setup ControllerSetup.exe. My system runs a 64-bit O/S … if you’re using a 32-bit O/S you’ll presumably just need to drop the (x86) part.

The repair took about two or three minutes, and low and behold I have my Visual Studio 2008 installation working just fine again!


Using Workbench to Build Applications on Remote Servers

By William Hawkins, Posted on February 18, 2010 at 4:21 pm

Avatar

I recently went to a customer site, to help them integrate Workbench into their OpenVMS development environment.  As a source code editor, the “integration” is relatively simple, you just need to have NFS/CIFS/SAMBA installed, and use it to make your OpenVMS (or UNIX) drives look like they’re actually Windows drives.  However, when you want to compile or link your application, you either need to go back to your telnet window and build it there, or you can download the RemoteBuild utility from the SynergyDE CodeExchange.  There are two versions for OpenVMS out there right now, both provided by Chris Blundell from United Natural Foods Inc.

Synergex PSG decided that we wanted to provide a remote build facility that could talk to multiple environments using information from a single Workbench project.  We wanted to minimize any potential firewall issues (for companies that have internal firewalls), and we also wanted to build on the SynPSG.System classes (distributed with ChronoTrack – our SPC 2009 demonstration application) for the network communication.  For those of you unfamiliar with the SynPSG.System classes, they are a partial implementation of the Microsoft System classes written in Synergy, (so they work on all supported platforms,) but when we have Synergy for .Net available, we'll be able to use the native .NET framework System class without modifying code. (ok, we'll have to change the import statements, but that should be all.)

So PSG has posted our flavor of a remote building application into CodeExchange – it's called remoteServer.   There is a client component to install into Workbench, and a server component (written in Synergy) that runs on each development server.  If you have both SAMBA (or equivalent) and remoteServer installed and configured, you are able to compile your application on the remote system, and in the unlikely event of a compile error (I know, you never have any coding errors) you will be able to double click on the error on the output window, and go straight to that line of code in the source file on your remote server.

If you work in a multi-platform development environment, I would encourage you to go download any of the remote build offerings in CodeExchange, and start using the power of Workbench to help improve the productivity of your developers.


Don't miss a post!

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

Recent Posts Categories Tag Cloud Archives