Monthly Archives: November 2012

The RXI Files

As you probably know OpenInsight has plenty of command line switches and naturally for version 10 we’ve managed to add some more.  Here’s a list so far of the old and new ones (We’ll take a look at the new ones in a later post):

Switch Description
TB Taskbar ID
AP Application ID
UN Username
PW Password
SN ServerName
QN QueueName
AE AutoExec
CA Caption
DV DevMode
SM Show Monitor
NS No Spy
HI Hide PS
HE Hide Engine
BN Show Banner
SI Single Instance
EL Elevate
MD Minimum Banner Display
EP Engine Path
2D Use Direct 2D rendering
DP Use DPI scaling

Of course remembering to add all these to a shortcut can be tedious and error prone, so a new feature of OI 10 is the RXI (Revelation Xml Ini) file. This is basically a configuration file that stores the equivalent of these switches for a specific application and is parsed when the Presentation Server is first booted.

The contents of an RXI file are simple XML which looks like this:

<revPS appID="SYSPROG">
 <taskBarID>RevX.SYSPROG</taskBarID>
 <serverName>\\.\REVXPS_DEBUG</serverName>
 <queueName></queueName>
 <autoExec>REV_IDE</autoExec>
 <bannerFile>revx.png</bannerFile>
 <caption>Revelation X Dev System</caption>
 <showBanner>1</showBanner>
 <showMonitor>1</showMonitor>
 <noSpy>1</noSpy>
 <hidePS>0</hidePS>
 <hideEngine>0</hideEngine>
 <singleInstance>1</singleInstance>
 <elevate>0</elevate>
 <minDisplaySecs>0</minDisplaySecs>
 <useD2D>1</useD2D>
 <enginePath>C:\RevSoft\RevX.Dev</enginePath>
 <useDPIScaling>1</useDPIScaling>
</revPS>

An RXI file can be created for each of your OI applications using the Application ID as the file name with an extension of “.rxi”, e.g.

  • sysprog.rxi
  • examples.rxi
  • zzxadm.rxi

To use the RXI file specify the appropriate Application ID with the “/AP” command line switch when you start OpenInsight.  It is important to note that any of the settings contained within an RXI file are overridden by it’s corresponding command line switch if the switch is present.

Another point to bear in mind is that just as with command line switches the information contained within an RXI file is only used when the Presentation Server is first booted.  For example if you boot into SYSPROG and then change the application to EXAMPLES the “examples.rxi” file will not be processed.  This is because the information in the RXI file can only be processed and applied at boot-time.

[Edit: 01 Feb 13 – AM switch renamed to TB and taskBarID]

[Edit: 08 Jan 13 – Added DPI Scaling modifications]

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

The new STYLE_N property

If you’ve ever had to work with the STYLE or STYLE_EX properties in OpenInsight you’ve probably had to write some gnarly code like this to get around the strange way it returns a string containing a C-style hex representation such as “0x8234ABDB”:

style = iconv( get_Property( object, "STYLE" )[3,8], "MX" )

We’ll probably never know the reason the original authors of OpenInsight decided to implement the property like this, but with version 10 we’ve provided a pair of new properties called “STYLE_N” and “STYLE_EX_N” that return the numeric (decimal) representation of a control’s style directly thereby saving the need for the extra parsing.

The LOG_EVENT method

In an earlier post we took a very brief look at some of the new properties of the SYSTEM object, and this time we thought we’d take a closer look at one of it’s new methods called LOG_EVENT.

Simply put the LOG_EVENT method allows you to write a message to the Windows Event Log without the need for you to prototype and use any Windows API functions yourself. It’s very easy to use and takes three arguments:

1) Type Info: This is a dynamic array comprised of the following fields:

   <1> Message Type (Required) : "ERROR", "WARNING" or "INFO".
   <2> Event ID     (Optional) : Integer denoting the event. Defaults to 1.
   <3> Category ID  (Optional) : Integer identifying the category. Defaults to 0.

2) Source Info: This is a dynamic array comprised of the following fields:

   <1> Event Source (Required) : Name of the Event Source (See below).
   <2> Server Name (Optional)  : UNC Name of the system to post the message to.
                                 Defaults to the local workstation.

3) Message Text: This is simply the text of the message to post to the Event Log.

Example: Post an error message to the Event Log from the “RevPS” Event Source:

   x = exec_Method( "SYSTEM", "LOG_EVENT", "ERROR", "RevPS", "FOOBAR!!!!" )

The Event Source name

So far, so good. However if you simply execute the above code you will see the message you posted in the Application Event Log, but you’ll also see that Windows has prefixed your message with some of it’s own text which refers to a missing Event ID description like so:

The reason for this is that Windows expects to find a “registered Event Source” containing the description for the Event ID that you specified.  A registered Event Source is actually a DLL containing a set of strings, each of which corresponds to an Event ID.  Without this DLL you get the warning text you see above which doesn’t look very professional and gives the impression that something is missing from your application.

For OpenInsight v10 we have provided a generic DLL called RevEventMsg.dll that you can register on your system under your desired Event Source name  – if you then use that name in your  call to the LOG_EVENT method you will see your message without any of the warning text prefixed to it.

Registering the DLL is quite simple: you need to create a new key with the name of your Event Source (We used the string “RevPS” for this example) under this path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\

… and set a couple of values like so (this can be automated easily via a .reg file):

Now if you call the LOG_EVENT method your Event Log entry will look like this:

Much better.

If you are interested in reading further on the subject of the Windows Event Log you can find full documentation on Microsoft’s MSDN website here,

[Edit: 24 Apr 13 – Call_Method renamed to Exec_Method]

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

The Set_Property_Only subroutine

One of the problems with the existing Set_Property function is that it also performs an implicit Get_Property operation to return the previous contents of the property to the caller.  In many cases this information is simply discarded after the “Set” making the “Get” call actually unnecessary, and this inefficiency goes unnoticed as the quantity of information retrieved during the “Get” is small.  However, in some cases the effect is noticeable: For example, setting the ARRAY property of an EditTable that contains several thousand rows to null (i.e. clearing it), will produce a noticeable delay while the ARRAY contents are accessed and returned.

A new subroutine, called Set_Property_Only, has been added to the OpenInsight 10.  This operates in the same way as the existing Set_Property function except for the fact that it doesn’t bother performing a Get_Property operation to return the previous property contents to the caller.  This helps you to optimize your code for better performance.