Monthly Archives: April 2013

Taskbar Integration – Overlay Icons

We have already looked at the TASKBARID property in an earlier posting but there are also several other properties that allow your OI forms to integrate closely with the taskbar via such items as overlay icons and progress bars.  In this post we’ll take a quick look at the new OVERLAYICON property.


This property allows you to specify an icon that will be superimposed onto the bottom right of your form’s taskbar button.  It is designed to highlight a status change in your program and is used by applications such as MSN Messenger to denote the user’s online status.

This property is similar to the standard ICON property where you simply specify the name and path of an icon file, or it’s DLL resource ID.


Form without an overlay icon

Form without an overlay icon

Form with an overlay icon

Form with an overlay icon

Further reading

More information on Overlay Icons can be found here, along with some guidelines on their usage here.

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

Editline Autocompletion

One of the new capabilities we’ve added to Editline controls in OpenInsight 10 is Autocompletion.  This is a common feature found in many modern programs where the system attempts to predict a word or sentence that the user is entering without actually typing it in completely.

To enable this the Editline control now supports the following new properties:



This property specifies if Autocomplete is active, and if so how the suggested string is displayed. It can be one of the following values:

  • “0” – Autocomplete is disabled
  • “1” – Autocomplete is enabled and in “append” mode: the remainder of the suggested string is added to the end of the characters the user has typed in and highlighted.
  • “2” – Autocomplete is enabled and in “suggest” mode:  the system displays a drop-down list of possible matches to what the user is typing.
  • “3” – Autocomplete is enabled and in “suggest-append” mode. This is combination of the previous two modes.


This property specifies where the list of possible suggested strings is obtained from.  It can be one of the following values:

  • “0” – Custom List: a list set via the AUTOCOMPLETELIST property
  • “1” – File List: a list of matching file and directory names supplied by Windows
  • “2” – Directory List: a list of matching directory names supplied by Windows
  • “3” – History List: a list of matches against the user’s URL history list
  • “4” – MRU List: a list of matches against the user’s MRU list
  • “5” – Shell List: a list of matches against all objects in the Windows Shell Namespace


This property specifies an @fm-delimited list of suggested strings to use when the AUTOCOMPLETESOURCE property is “0”


Autocomplete from a custom list


Autocomplete from a file list


Autocomplete from URL history


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

OpenInsight and High-DPI

With the increasing popularity of high-resolution monitors, one of the biggest usability problems today is the display size of text and UI controls, because they appear smaller as the screen resolution increases. The recommended advice to overcome this is to increase the DPI (dots-per-inch) setting of the system, thereby enlarging these elements and making them easier to see and read. If you’ve been using Windows Vista and above you’ve probably already seen this Control Panel applet that allows you to easily change your DPI settings:

DPI Control Panel Applet

Windows 7 DPI Control Panel Applet

However, unless an application is designed to be DPI-aware this can result in some unsatisfactory results, such as over-large fonts, clipped controls and blurry windows. This is because many older Windows applications assume a constant DPI (96) when setting font and size coordinates and they do not apply any scaling to these values, thereby resulting in the aforementioned problems.

(NB. The “magic number” of 96 that you’ll see throughout this post is due to the fact that at 96 DPI one logical pixel is equal to one screen pixel – this is the “100%” setting in the Control Panel applet shown above).

In an effort to accommodate these applications Microsoft have introduced a couple of OS features over the years:

  • On Windows XP the system fonts and some system UI elements are scaled up at runtime, but this leads to the common problem of text appearing larger and being clipped as the actual size of the bounding control is usually not scaled.
  • On Windows Vista and above a feature called “DPI-virtualization” automatically scales windows belonging to an application not marked as “DPI-aware” – in effect they are rendered at 96 DPI to an off-screen bitmap, resized, and then drawn to the screen, but this can result in some blurry windows due to pixel stretching.  OpenInsight 10 is marked as a DPI-aware application so will not be subjected to DPI-virtualization.

OpenInsight 10, High-DPI and automatic scaling.

OpenInsight 10 supports High-DPI by automatically scaling-up all GUI objects at runtime when created through the SYSTEM object’s CREATE method (formerly known as the “Utility CREATE service”). This affects the following two properties:

  • Size coordinates
  • Fonts

The actual scaling for coordinates is calculated by the following simple formula:

screenPixels = logicalPixels * ( currentDPI / 96 )

For example, if you create a control with a size of 200×100 and you are running at 144 DPI (i.e. 150% as per the Control Panel applet above) then the control will be created with an actual size of 300×150 pixels.

The font point size is similarly multiplied by the scaling factor (i.e. currentDPI / 96 ).

Supporting images under High-DPI

Another noticeable issue when running at high DPI settings are images, which are assumed to have been designed for 96 DPI and therefore have to be scaled up at runtime leading to a potential loss of quality due to the resize.  To help with this the tool-set has been extended to allow repository BITMAP entities to specify multiple image files when being defined. The first will be used for 96 DPI (100%), the second for up to 120 DPI (125%), the third for up to 144 DPI (150%) the fourth for up to 192 DPI (200%) and so on, with further images being defined at 48 DPI (50%) increments (for future-proofing). When a control is created at runtime the system picks the appropriate image size and scales it as needed (preferably down where possible) before applying any other transformations.

Note that this does NOT apply to images set at runtime in code via the BITMAP property.  In this case the developer is assumed to have selected the correct image file size regardless of the DPI setting.

Designing under High-DPI

If you design your forms when running under a High-DPI setting the Form Designer will save and compile all coordinate and font information as though you were developing at 96DPI, so the values will be scaled down appropriately.

Opting out of automatic scaling

Of course, we always try our best not to break existing applications so you can set an option in the RXI file to turn off the automatic DPI scaling if you wish (this option is exposed at runtime via the read-only SYSTEM DPISCALING property).

This same principle can also be applied to individual windows at design-time so you can use it selectively as needed (WINDOW objects also support the read-only DPISCALING property).

Further reading

If you want to find out more information on this topic please see the following link to Microsoft’s documentation on MSDN:

Writing High-DPI Win32 Applications

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