Tag Archives: Deployment


As most of you will probably know, “commuter module” is the term given to a stored procedure whose main purpose is to handle event processing for a specific form.  Rather than have each individual event processed in a separate event script, quick-events are used instead to call the commuter module directly, passing it various parameters such as the name of the object firing the event, the name of the event itself, and any relevant arguments.  The commuter module then branches off to different internal subroutines to handle the event.

Following this methodology offers several important advantages:

  • Simplified code management
  • Simplified deployment
  • Improved code sharing via internal subroutines
  • Lower memory overhead (single procedure vs. multiple event scripts)

While using a commuter module like this is the recommended way of developing applications in OpenInsight, there has never been any sort of formal link between the commuter module and the form itself, which means that it is usually necessary to adopt a naming convention for this approach to work.

For example, it is common to have a commuter module with the same name as the form, or with the same name as the form and suffixed with the string “_EVENTS”.  By doing this it was easy to define quick-events to call the commuter module in the old v9 Form Designer like so:

v9 Commuter Module Quick Event

v9 Commuter Module Quick Event

The OBJ_CALL_EVENT program looks for a stored procedure with the same name as the form, or one with the same name as the form and suffixed with “_EVENTS”.  It was also possible to avoid the overhead of a lookup and call the commuter module directly by using the “@WINDOW” placeholder like this:

v9 Commuter Module Quick Event (using @WINDOW)

v9 Commuter Module Quick Event (using @WINDOW)

Or the “@WINDOW_EVENTS” placeholder like this:

v9 Commuter Module Quick Event (using @WINDOW_EVENTS)

Of course, even with this approach the form still wasn’t actually linked to it’s commuter module, rather it was only linked to “OBJ_CALL_EVENTS” or a fictitious entity called “@WINDOW”.

In version 10 we’ve added a new WINDOW property called COMMUTERMODULE, which simply contains the name of the stored procedure to use (this can be any valid name – you are no longer limited to one based on the name of the form, though we do suggest you keep this convention to help organize your application):

CommuterModule Property

CommuterModule Property

When the form is saved and compiled this stored procedure is linked to the form with a “used-by” relationship, thereby making deployment easier as you will see the link when you create your RDK definition records.

Another benefit of this is that you can quickly open your commuter module from the form by using the “View Commuter Module” button on the Form Designer toolbar:

View Commuter Module button

View Commuter Module button

Finally you can easily set your quick events to call your commuter module in the Event Designer like so:

Commuter Module QuickEvent

Commuter Module QuickEvent

Note that it uses an “@COMMUTER” placeholder – this is replaced with the contents of the COMMUTERMODULE property at runtime.

(You can still use the previous @WINDOW/_EVENTS or Obj_Call_Events methods if you wish – those options still exist.)

So, this is the first step in tightening the relationship between a form and it’s commuter module.  There is certainly scope for more integration between the two and this is something that we hope to pursue during subsequent releases.

(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10)

OpenInsight 10 and the Visual C++ 2015 Runtime

As we’re aiming to update the core OpenEngine code to be a cross-platform solution we spent some of last week moving the OpenInsight 10 C++ codebase from Visual Studio 2010 to Visual Studio 2015, to take advantage of better C++ standards support and the improved tools, such as the excellent C++ static code analyzer.

All in all it was a fairly smooth process, apart from a “hidden” default compiler setting that managed to temporarily break the High DPI and scaling code, but that sort of thing is expected when moving versions, so after a fair bit of Google-Fu we found the issue and fixed it.  One big difference we did find however, is how Microsoft have changed the way their C-runtime libraries are distributed, and it’s something of a departure from previous versions.

As you may or may not be aware, programs built with Visual C++ rely on a set of core DLLs, usually known as the “VC++ Redistributable” and this can be deployed in one of two ways:

  1. The DLLs can be included in the application directory – this is the “App-folder” method,
  2. The DLLs can be installed into the system directories via a “VC++ Redistributable” setup program, which is basically another client-install program.

In order to save you the extra pain associated with yet another client-install  we opted to use the App-Folder method for OpenInsight 10, as originally this meant we supplied you with just two extra DLLs.  However, for Visual Studio 2015 Microsoft have decided to do some refactoring to share their C-runtime code between Desktop apps and the new Universal Platform apps, and so at first glance it looked we needed to supply four DLLs instead, these being:

  • concrt140.dll
  • msvcp140.dll
  • vccorlib140.dll
  • vcruntime140.dll

But unfortunately this was not the end of the story, as early testing on some machines showed that there were still some required DLLs missing.  As it turns out these four DLLs rely on a further set of DLLs that Microsoft say are now “part of the operating system”, and although we could supply these too there are actually 41 of them!  Needless to say we won’t be cluttering up your OpenInsight folders with these.

On further investigation it appears that Microsoft are indeed releasing this 41-DLL set through Windows Update, but only as an Optional Update, so its quite possible that systems will not have these installed and this is something to bear in mind (The update in question is KB2999226).

So, when deploying OpenInsight 10 you have the choice of:

  1. Ensuring KB2999226 is installed on the workstation, or
  2. Using the “Visual C++ Redistributable for Visual Studio 2015” setup package instead.

At the moment we are going with option (1), but this post is basically a “heads-up” to make you aware of the choices.

(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).