As promised in our last post this time we’re going to cover the new properties we’ve added to the Presentation Server to support the enhanced image capability:
We have also added the following new method:
This property specifies how a clipped or scaled image is aligned within a client area. It can be one of the following values:
Examples:
IMAGEALIGN 4 (Centered)
IMAGEALIGN 6 (Bottom-Left)
This property specifies how the image is rendered onto the window’s client area. The following property values are supported:
Examples:
IMAGESTYLE 1 (Tiled)
IMAGESTYLE 2 (Stretched)
IMAGESTYLE 3 (Scaled), IMAGEALIGN 5 (Center-Right)
This property specifies the color to use as the transparent color when rendering the image as described in this post. It basically replaces the current (and undocumented)IMAGETRANSPARENT and TRANSPARENTCOLOR properties, both of which have been deprecated with this release.
This property should be a valid RGB color value or one of the following special values:
Some image formats such a GIF and TIFF files can contain more than one image, held in series of frames. This read-only property returns the number of frames in the image file. Note that this is not the same as the IMAGECOUNT property, which applies to a single frame only.
Example:
Animated GIF with 12 frames
This property gets or sets the current display frame for the image and could be used with a TIMER event to display an animated GIF file for example. Note that this property is not the same as the IMAGENUMBER property which applies to a single frame only.
Examples:
Animated GIF with IMAGEFRAMENUMBER of 2
Animated GIF with IMAGEFRAMENUMBER of 10
This read-only property returns a dynamic array containing the size of the image in pixels:
<1> Width <2> Height
Note that for a multi-frame image format it returns the size of a single frame, not all the frames combined.
This property specifies the transparency of the entire image as it is rendered onto the window. It is based on simple percentage amount, “0″ being fully opaque and “100″ being fully transparent (and therefore not visible).
Example:
IMAGETRANSLUCENCY of 70 with IMAGEORIGIN of 90,60
This method supersedes the existing IMAGE property and allows a image to be set by passing the raw image data rather than by passing a file or resource name as per the BITMAP property. The OpenInsight property interface is text-based and does not support passing binary data with embedded null characters, whereas the method interface does, hence the reason for this change.
The following current image-related properties remain the same:
The following properties have been deprecated or removed in OpenInsight 10:
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
In a previous post we looked at some the enhancements to the version 10 System Monitor to make it a more user-friendly tool. However, one of the features we didn’t mention was the addition of a Basic+ property API so you can interact with it from your own programs and tools if you wish. This API is exposed via the new SYSTEMMONITOR object, which supports the following properties:
And the following method:
This property returns the window handle (HWND) of the System Monitor window.
This property returns the contents of the results edit box in the System Monitor.
This property gets and sets the size and position of the System Monitor window. It has the same format as the normal OpenInsight WINDOW SIZE property.
This property gets and sets the caption text of the System Monitor window.
This property gets and sets the visibility of the System Monitor window. It has the same format as the normal OpenInsight WINDOW VISIBLE property
This method executes a system monitor command.
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
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:
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:
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:
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).
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:
This property specifies where the list of possible suggested strings is obtained from. It can be one of the following values:
This property specifies an @fm-delimited list of suggested strings to use when theAUTOCOMPLETESOURCE property is “0”
Examples:
AUTOCOMPLETESOURCE 0, AUTOCOMPLETEMODE 2
AUTOCOMPLETESOURCE 1, AUTOCOMPLETEMODE 3
AUTOCOMPLETESOURCE 3, AUTOCOMPLETEMODE 1
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
Page 13 of 24
