In the previous post where we introduced the new RXI files we mentioned some new command line switches added to OpenInsight 10. In this post we’ll take a look at them and describe what they do.
Under Windows 7 and 8 multiple instances of an executable launched from the same directory are grouped under one icon on the taskbar, making navigating between them quite tedious. To allow an executable to override this behavior Microsoft introduced a new application property called the “Application User Model ID” – a simple string that can be applied to an executable instance to differentiate it from other sibling instances, thereby allowing them to be un-grouped.
Windows assigns a default value to this property at runtime based on the executable name and the starting directory. The OpenInsight /TB switch (or taskBarID element in an RXI file) allows you to set your own unique value for this property so that your application can be differentiated on the Windows taskbar (A read-only property called TASKBARID is exposed by the SYSTEMobject at runtime to provide access to this value).
The Application User Model ID must be set before any forms are created by an executable which is why it can only be set via the RXI file or the command line switch.
If you wish to find out more details about the Application User Model ID please see the MSDN documentation about the SetCurrentProcessExplicitAppUserModelID function.
This is a boolean (1/0) flag that ensures there is only one instance of the specified OI application executing on a workstation. Any other OI applications from the same executable are unaffected.
This is a boolean flag (1/0) that specifies if the application requires Administrator privileges when it is launched. If this switch is set to “1” and the Windows user is not an administrator they will be asked to provide Administrator level credentials before they can continue (via the standard Windows UAC prompt).
When displaying a banner image file at startup this switch specifies the minimum number of seconds to display the banner for.
This switch specifies an alternative OpenEngine path (normally the Presentation Server expects to load OpenEngine from the same directory where it is located).
This is a boolean flag (1/0) that specifies if the system should use Direct2D technology for rendering when available. By default OpenInsight will attempt to use Direct2D where it can (Windows Vista SP2, Windows 7 and later), but it can be forced to use GDI rendering instead if this flag is set to “0”.
This is a boolean flag (1/0) that specifies if the application should automatically scale coordinates when used on a high-DPI system.
[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).
From a tool-developers point of view one of the weaker areas in the Presentation Server has always been the lack of a “reflection API”, i.e. a way to discover what properties, methods and events an object actually supports at runtime. This in turn has led to creating manual lists and records of object attributes, bringing with it with the inherent difficulty of keeping this information up-to-date as new features are added.
Primarily designed with the new PS-based Form Designer in mind, this shortcoming has been addressed in version 10 with the addition of the following new methods to the SYSTEM object:
Each of these methods takes a single argument which is the type of object to query:
e.g.
buttonProperties = exec_Method( "SYSTEM", "REFLECT_PROPERTIES", "PUSHBUTTON" ) buttonMethods = exec_Method( "SYSTEM", "REFLECT_METHODS", "PUSHBUTTON") buttonEvents = exec_Method( "SYSTEM", "REFLECT_EVENTS", "PUSHBUTTON" )
Each method in turn returns a dynamic array of information describing the requested attribute type:
Note that when these methods return the type of data for a property or argument there are some cases where only a broad hint is given – Basic+ is an untyped language so it is not really feasible to accurately describe some types using a simple set of flags – e.g. in the case where an argument is a complex dynamic array containing a variety of other core data types such a strings and numbers.
Whilst aimed mainly at developers who write development tools for OpenInsight, this API may still be of interest for those of you who like to write your own diagnostic and debugging tools – when a new property, method or event is added to the Presentation Server it is clearly exposed thereby reducing the likelihood of it remaining hidden and undocumented.
[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).
One of the most critical components of the Presentation Server is the System Monitor – as well as providing a simple command line interface to your forms and Basic+ Stored procedures, it is also responsible for a lot of hidden message processing and routing, such as providing the underlying framework that implements the IDLEPROC property and the POST_EVENT function. It’s always there, even when you think you’ve closed it.
Needless to say it’s also the first part of the Presentation Server that gets written, and while the existing System Monitor is quite basic (it hasn’t been changed for many years) we’ve taken the opportunity with OI v10 to make it a bit more powerful and user-friendly.
Here’s a brief overview of the changes we’ve made:
We’ve also added the following commands:
Be sure to let us know if there’s any features you’d like to see added to the System Monitor, but be advised that requests for full TCL compatibility will be ignored!
[Edit: 14 Jan 13 – Added CLL command and AutoComplete note]
[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).
As you may have noticed in a previous post on RXI files OpenInsight 10 provides the option to use Direct2D rendering when painting windows and controls on the screen. If you’re not familiar with Direct2D it’s a new graphics engine Microsoft introduced with Windows 7 that aims to replace the traditional GDI graphics interface that has been a part of Windows since time began. Essentially it’s a hardware-accelerated API that takes advantage of modern GPUs to provide high-performance rendering of 2D geometry, bitmaps and text.
(The official MSDN Direct2D documentation can be found here).
By default OpenInsight will use Direct2D if it is available on the platform (usually Windows 7, Windows 8 and Vista SP2) unless you override this via the aforementioned /2D switch or the UseD2D option to turn it off. You can also disable it at runtime by using the SYSTEMobject’s D2D property, which takes a simple boolean value of 1 or 0.
Of course you’re probably asking why you would want to disable this? Well, to be honest you probably don’t, but it’s a sad fact that not all graphics cards are created equal (or at least their drivers aren’t) and it’s nice to have the option to drop back to standard GDI rendering in case you ever run across a problem. We’ve also found it useful during our own development cycle here to see how the system behaves when Direct2D is not available, such as when running on an XP platform (of course we do actually test on XP itself, but switching platforms mid-development slows the entire process down, so initial testing of GDI rendering is done on Windows 7).
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
Page 11 of 24
