News and Updates for Synergy/DE Developers
SYNERGY-E-NEWS
News and Updates for Synergy/DE Developers

June 30, 2011

 
"SPC 2011 rocked and unleashed the power of Synergy when combined with .NET"
The SPC comes to an end in Oxford—see what attendees had to say

SPC 2011 came to a close in Oxford, UK, on June 16. Just as in Chicago a few weeks prior, Synergy/DE developers spent three action-packed days acquiring knowledge and significant new skills in both Synergy/DE and the computer industry overall, enabling them to immediately extend their applications with the latest technology. Per Oxford attendee Aditya Cavuturu from Equiniti ICS, “SPC 2011 rocked and unleashed the power of Synergy when combined with .NET."


Free Code!
Send an e-mail from a Synergy program

The topic of sending e-mail from a Synergy program makes a regular appearance on Synergy-l, so you may already be familiar with the SMTPmail entry in Synergy CodeExchange. This program, which illustrates how to send an SMTP Mail message from a traditional Synergy program, was recently updated to work with Synergy/DE 9.5.

Click to read the rest of the article

Synergy/DE Tech Tip

I have set up a 64-bit Windows machine and have both 32-bit and 64-bit Synergy installed, but am getting a variety of licensing errors when trying to run Workbench, compile, or run dbr.


Platform News
Read a selection of recent articles from around the web
Extending your Synergy applications with MEF
By Jeff Greene, Synergy/DE Software Engineer

Writing big software is hard. Customers want customization, and writing big extensible software is harder still. OOP has been promising extensibility and reusability, so this should be easier now right? Well, no, but we can force the issue and bring vast extensibility with a pleasant syntax. We’re going to do this using the Managed Extensibility Framework (MEF) that was released as part of .NET Framework 4.0.


PSG Blog: Building distributed apps with Synergy/DE and WCF
By Steve Ives, Sr. Synergy/DE PSG Consultant

At the recent SPCs in Chicago and Oxford several of the sessions that I presented were focused on networking, and in particular on the various tools and technologies that are available to Synergy developers to allow them to build and deploy distributed software applications. In particular I spent quite a bit of time talking about a technology called Windows Communication Foundation (or WCF).


Quiz
Synergy/DE pros, see if you can answer this question!

Given the following Repository schema and the following UI Toolkit window script, at what position in the data structure does the field "x" referenced in the window begin?


Synergex Holiday Reminder

We will be closed on Monday, July 4, in recognition of the Fourth of July holiday.

 


"SPC 2011 rocked and unleashed the power of Synergy when combined with .NET"
The SPC comes to an end in Oxford—see what attendees had to say

SPC 2011 came to a close in Oxford, UK, on June 16. Just as in Chicago a few weeks prior, Synergy/DE developers spent three action-packed days acquiring knowledge and significant new skills in both Synergy/DE and the computer industry overall, enabling them to immediately extend their applications with the latest technology. Per Oxford attendee Aditya Cavuturu from Equiniti ICS, “SPC 2011 rocked and unleashed the power of Synergy when combined with .NET." Visit the SPC web site to see other attendees’ comments, and visit the PSG blog for commentary from the Synergex Professional Services Group.



Extending your Synergy applications with MEF
By Jeff Greene, Synergy/DE Software Engineer

Writing big software is hard. Customers want customization, and writing big extensible software is harder still. OOP has been promising extensibility and reusability, so this should be easier now right? Well, no, but we can force the issue and bring vast extensibility with a pleasant syntax. We’re going to do this using the Managed Extensibility Framework (MEF) that was released as part of .NET Framework 4.0. But first let’s decide if you care or not by answering the following questions:

  • Do you have a set of core libraries that are used to provide functionality throughout several different applications?
  • Do your customers ask for customizations but the thought of maintaining several divergent implementations causes your stomach to churn?
  • Do you need to deploy new functionality that doesn’t fit in a patch but isn’t really worth an entire release?
  • Do your customers sometimes say, “I just want [small functionality enhancement ‘X’]; can I write some sort of plugin?”
  • Are you using .NET?
  • Are you interested in acronyms consisting of 3 letters?

If you answered yes to more than one of these, you and MEF will get along just fine.

MEF is the new extensibility framework for .NET. As Microsoft puts it, “Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed.” With MEF, programs import extenders (i.e., plug-ins) by stating what they need, extenders export discoverable parts, and MEF puts it all together (i.e. composes it). Now that Synergy Language is a .NET language, MEF is available to be used in your Synergy applications. Just add a reference in your Synergy project to the System.ComponentModel.Composition assembly, and start importing, exporting, and composing with MEF.

In the snippets that follow, we’ll make a class called Program that logs its actions. We will use MEF to enable Program to be extended without it knowing anything about its extenders and without its extenders knowing anything about Program.  Let’s dive in by breaking down a simple snippet:

class Program
	{Import}
	Logger, @ILogger
endclass
The first part is pretty normal; we’re just declaring a class named Program. Then we get to the Import attribute on a field named Logger of the type ILogger. The purpose of this attribute is to let MEF know that we’re looking for an ILogger and, (if it would be so kind) we would really appreciate it if it would provide us with one. So we’re done right? We ask for a logger, MEF kindly gives us one, and it just does whatever we’ve imagined an implementation of ILogger would do. Err…ummm, that’s not quite right. Let’s try that again. MEF only knows types we’ve told it about. So here’s another snippet to break down:
{Export(^typeof(ILogger))}
public class ConsoleLogger implements ILogger   
       public method Log, void
              message,  @string
       proc
              Console.WriteLine(message);
       endmethod
endclass

Given that an Import attribute tells MEF we want something, Export tells MEF we want to give it something. But Export also needs to know more specifically what we want to expose, so we pass it the ILogger type.

Now we’ve got something that imports and something that exports, so we must be done. Well not quite. Someone needs to tell MEF that we want to hook what we’ve exported to what we’ve imported. I feel another snippet coming on:

public static method MakeProgram, @Program
record
      madeProgram, @Program
      catalog, @AssemblyCatalog
      container, @CompositionContainer
proc
      madeProgram = new Program()
      catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly())
      container = new CompositionContainer(catalog, new ExportProvider[0])
      AttributedModelServices.ComposeParts(container, new object[#] { madeProgram })
      mreturn madeProgram
endmethod

We start off specifying a static method that returns a new instance of Program. Once we make the basic instance, we need to get a catalog of all the available MEF parts. In this case we’re going to look at the current assembly since that’s where everything resides this simple example.  Once we’ve got our parts we can make a CompositionContainer and use ComposeParts to put the pieces togher as madeProgram. 

Wow, that looks like a lot more effort than just setting Logger to be a new ConsoleLogger. I’m not going to dance around it; it is a lot more effort. But it’s worth it since the code can be made to work with a lot more than just Program and ConsoleLogger.

So now we’ve got Logger being composed as a ConsoleLogger, but what if ConsoleLogger wants to import something. Well, that may sound like it’s going to get complex, but it’s not. It actually gets easier since all we have to do is Import/Export what we want. Then, when ConsoleLogger gets instantiated, MEF calls ComposeParts for us.  This makes it easy for your main application to provide services that can easily be consumed by extensions. It also makes it easy for your extensions to use default implementations or take advantage of other extensions in order to do their work.  There are many more things you can do with MEF. I would recommend taking a look at the MEF Programming Guide for a more-than-cursory glance at MEF.

[Code Listing]

import System
import System.Reflection
import System.ComponentModel.Composition
import System.ComponentModel.Composition.Hosting

namespace SENMEF
    main     proc
         Program.MakeProgram().DoStuff()
    endmain
    class Program
{Import}
protected Logger, @ILogger

public static method MakeProgram, @Program
record
  madeProgram, @Program
catalog, @AssemblyCatalog
 container, @CompositionContainer
proc
madeProgram = new Program()
catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly())
     container = new CompositionContainer(catalog, new ExportProvider[0])
    AttributedModelServices.ComposeParts(container, new object[#] { madeProgram })
     mreturn madeProgram
endmethod public method DoStuff, void
           proc
                  Logger.Log("Hello Extensibility")
           endmethod
    endclass public interface ILogger
           method Log, void
           message, @string
          endmethod
   endinterface public interface IConsole
          method Print, void
          text, @string
          endmethod endinterface {Export(^typeof(IConsole))}
    public class SystemConsole implements IConsole
          public method Print, void
          text, @string
          proc
                 Console.WriteLine(text)
          endmethod
    endclass {Export(^typeof(ILogger))}
   public class ConsoleLogger implements ILogger
          {import}
          TheConsole, @IConsole       public method Log, void
          message, @string
          proc
                   TheConsole.Print(message);
          endmethod
   endclass
endnamespace



PSG Blog: Building distributed apps with Synergy/DE and WCF
By Steve Ives, Sr. Synergy/DE PSG Consultant

At the recent SPCs in Chicago and Oxford several of the sessions that I presented were focused on networking, and in particular on the various tools and technologies that are available to Synergy developers to allow them to build and deploy distributed software applications. In particular I spent quite a bit of time talking about a technology called Windows Communication Foundation (or WCF). Click to read the rest of the entry.


Free code!
Send e-mail from a Synergy program

The topic of sending e-mail from a Synergy program makes a regular appearance on Synergy-l, so you may already be familiar with the SMTPmail entry in Synergy CodeExchange. This program, which illustrates how to send an SMTP message from a traditional Synergy program, was recently updated to work with Synergy/DE 9.5. And now it's been joined by SynNetMailDemo, which presents an example of how to send an e-mail message from a Synergy .NET program, using classes in the .NET Framework System.Net.Mail namespace. To run SynNetMailDemo, you'll need Synergy/DE 9.5.1a, including Synergy Language Integration for Visual Studio and Workbench, as well as Visual Studio 2010. Next time you're stumped by an e-mail question, check Synergy CodeExchange. It's possible that one of these programs will hold the solution.



Synergy/DE Tech Tip
Licensing error on a Windows machine with both 32-bit and 64-bit Synergy installed

Question:
I have set up a 64-bit Windows machine and have both 32-bit and 64-bit Synergy installed, but I am getting a variety of licensing errors when trying to run Workbench, compile, or run dbr.

When I try to launch Workbench, I get this error:
Cannot access license file (or Windows registry) (syserr 2)
When I try to compile from the command line in 32-bit, I get this error:
C:\> dbl
License management problem – Cannot access license file (or windows registry)

And when I try to run from the command line in 32-bit, I get all this:
%DBR-R-LMFAIL, Licensing failure
%DBR-I-ERTXTN, System error code: 2
%DBR-I-ERTEXT, Cannot access license file (or Windows registry)
%DBR-I- ERTXTN, System error = 2

There’s obviously something wrong with the licensing setup, but what?

Answer:
This happens when you have 32 and 64 and there’s a problem with the 32-bit license manager. If it was not configured, or if the configuration points to either a non-existent or incorrect license server, these types of errors will be generated. Remember, when running 32-bit Synergy on a 64-bit machine, the 32-bit installation must be a license client.

To correct this problem, run the Synergy Configuration Program for the 32-bit installation of Synergy. If License Manager is not configured, you’ll get a message to that effect and be directed to the setup dialog. If it is configured, click the Advanced button on the Licensing tab, and then change the value in the Server name field to a valid license server for the 32-bit installation.



Quiz
Synergy/DE pros, see if you can answer this question!

Given the following Repository schema:

Structure POINT    USER DEFINED
   Description "Defines an X, Y coordinate pair"
Field X   Type INTEGER   Size 4
   Description "Horizontal coordinate"
Field Y   Type INTEGER   Size 4
   Description "Vertical coordinate"
Structure LINE   USER DEFINED
   Description "Describes a line by two endpoints"
Group POINT1   Reference POINT   Type ALPHA
   Description "First coordinate"
Group POINT2   Reference POINT   Type ALPHA
   Description "Second coordinate"

And the following UI Toolkit window script:

.script
.input i_point, 2, 20
.repository line
.field x .field y
.end

At what position in the data structure does the field "x" referenced in the window begin?
a. 1
b. 9
c. This does not compile because X doesn't exist in LINE.
d. This does not compile because X is not unique in LINE.





Synergex Holiday Reminder
We will be closed on Monday, July 4, in recognition of the Fourth of July holiday.

If you anticipate needing our assistance on this day, please email us at synergy@synergex.com to make arrangements.