- Details
As you know some controls in OpenInsight support a set of properties called the Glyph API, and this has now been extended to EditLine controls as well. Of course it’s not the full API (see the supported properties below), as that wouldn’t make sense, but it does allow you to insert an image to the left or right of your text:
So now you can insert a handy search icon into your control, or perhaps a warning icon if the data in the control is invalid.
The following Glyph API properties are supported for EditLines:
- GLYPH (similar to the BITMAP or IMAGE property)
- GLYPHALIGN (Vertical and center settings are ignored)
- GLYPHCOLORKEY
- GLYPHCOUNT
- GLYPHFRAMECOUNT
- GLYPHFRAMENUMBER
- GLYPHOFFSET
- GLYPHORIGIN
- GLYPHSIZE
- GLYPHTRANSLUCENCY
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
- Details
In a previous post we mentioned that the EditLine control now supports the Glyph API, we’ve also extended the Image API to both EditLines and EditBoxes, along with gradient background colors and translucency. Here are a few examples showing the results:
Gradient BACKCOLOR
TRANSLUCENCY Property
IMAGE Property
IMAGETRANSLUCENCY Property
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
- Details
We’ve taken a look over the last few posts at some of the new features we’ve added to EditLine controls, but before we leave them we’ll mention a few miscellaneous new properties that you might find useful:
- AUTOSELECT
- CUEBANNER
- EXITCHARS
- VALIDCHARS
AUTOSELECT Property
This is a simple boolean property. When set to TRUE all text in the control will be selected when the EditLine is given focus.
CUEBANNER Property
This is a string property that contains the text to display when an EditLine has no data. The text is normally displayed in a faded style to differentiate it from “real” text. It is intended primarily to give the user a simple hint on the purpose of the EditLine, or on the format of the data it should contain.
EXITCHARS property
This property allows you to specify one or more characters as “Exit” characters, which means that if a user types any of them into the control the focus is automatically moved to the next control in tab-order as though they had hit the Tab key. This property is a simple string containing the Exit characters.
// Move to the next control if the user enters a "." or a space exitChars = ". " call set_Property( @window : ".EDL_IP1", "EXITCHARS", exitChars )
Note this property does not work if the PASSWORDSTYLE property is TRUE.
VALIDCHARS Property
This property allows you to specify one or more characters that are “Valid” characters, which means that the user can only enter these characters into the control. This property is a simple string containing the characters that are allowed.
// Only allow numeric characters in EDL_NUMBER validChars = "0123456789" call set_Property( @window : ".EDL_NUMBER", "VALIDCHARS", validChars )
Note this property does not work if the EDITMASK property is set or the PASSWORDSTYLEproperty is TRUE.
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
- Details
As you may (or may not) know variables in Basic+ are passed to stored procedures “by reference”, meaning that if you change a passed variable in the called procedure, that change is reflected in the calling routine (a fuller explanation of how this works can be found here). This behavior is critical to the way many system functions work (such as iconv and oconv) and is very useful in returning more than one item of data from a called procedure.
However, one place where this rule breaks down is when calling stored procedures via a QuickEvent, such as routing an event to a commuter module like so:
When you call a stored procedure in this way the system eventually passes your request to a routine called ExecNpHandler() which dispatches the event and its arguments to the desired target, However at this point the pass-by-reference chain gets broken because a copy of the argument is passed to the stored procedure rather than the original.
For example, if we used Send_Event() to trigger the OMNIEVENT event in the above example, and the commuter module changed Param2, the Send_Event() caller would not see the change (Note that if you use an Event Script handler then passing the event arguments by reference works as you would expect, and you will see changes made to your arguments by the Event Script handler).
While working on the v10 IDE this proved to be something of a problem because the framework relies on a series of OMNIEVENT calls to pass messages between various entities, and sometimes arguments are updated to let the caller know of things like state changes and suchlike. With something as complex as the IDE, writing the events as a series of Event Scripts was impractical so we took the opportunity to update ExecNpHandler() to respect the pass-by-reference paradigm instead – Now you get to see your changes in a consistent manner regardless of whether you prefer Event Scripts or QuickEvents.
So, is this change likely to impact you? In most cases the answer is no as ExecNpHandler() is normally the last handler to be called in the event chain, and any changes to passed arguments are usually ignored. Where this might be an issue is when:
- You call forward_Event() from an Event Script, or fire an event via Send_Event(), and
- You rely on the arguments you passed to either of the above functions remaining unchanged, and
- You changed the arguments passed to you in the commuter module, either by carelessness or design.
In this set of circumstances you will probably see an effect, and you may have to modify your code accordingly.
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).
- Details
In a previous post we looked at OpenInsight’s new features for running on High-DPI systems, and we described how forms can properly scale themselves to take advantage of better resolutions, thereby avoiding unnecessary blurring as the window manager tries to compensate when faced with a non-DPI-aware application:
In the example above both forms are running on a desktop set to 144 DPI (150%). The top form is running under OpenInsight v9 and, as you can see, has been stretched by the system resulting in blurry outlines, icons and text. In contrast, the bottom form is running under OpenInsight v10 and has been scaled correctly – the checkbox image and icon are sharp and the font has been scaled to the correct point size. (A word of caution – if your own system is set to use High-DPI don’t bother viewing this image on a Chrome-based browser unless you’ve set _it_ to use High-DPI as well – generally Chrome doesn’t handle automatic High DPI scaling like IE and FF, so the image above will still appear blurry, as will this text!).
However, with the release of Windows 8.1 Microsoft have made some significant changes in this area that has also led to changes in OpenInsight’s High-DPI handling as well. Until Windows 8.1 the DPI setting for the system was constant across all monitors and fixed during the login process – selecting another DPI setting required logging out and back in again, or even a full reboot in the case of Windows XP. Now, with the steady increase in monitor resolutions across different form factors, Microsoft have added the ability to set the DPI per monitor, which means that forms created on one monitor may look too small or too big when moved to another monitor with a different DPI.
In order to deal with this at runtime, top-level forms are now notified by a new Windows message called WM_DPICHANGED, which is sent when either of the following happens:
- The DPI of the monitor a form is displayed on changes, or
- The form is moved between monitors that have different DPI settings.
This message is used by OpenInsight to adjust the scale of a form dynamically as required, so if a form’s DPISCALING property is TRUE you will see this happen as you drag it across monitors with different DPIs. All the rules described in the original post still apply of course:
- Fonts are scaled
- Coordinates are scaled
- DPI-aware images are selected and/or scaled
(We’ve also added a new property called DPI to the WINDOW object, which returns the DPI of the monitor that the window is currently displayed on).
The fact that scaling has moved from a static to a dynamic operation has also led to the implementation of a new OpenInsight WINDOW property called SCALEFACTOR, which allows you to set the scale of a form to an arbitrary value at runtime, regardless of any DPI setting. We’ll take a look at this property in the next post.
In the meantime, you can find more information on Windows 8.1 per-monitor DPI scaling here:
- Windows 8.1DPI Scaling Enhancements
- High DPI for desktop apps in Windows 8.1
- High DPI Support for IT Professionals
- Making your Desktop Apps Shine on High-DPI Displays (video – Build 2013)
(Disclaimer: This article is based on preliminary information and may be subject to change in the final release version of OpenInsight 10).