Beppe Platania's blog

Windows Embedded Standard 7: User interface filters

(Post 1 of 4)

One of the most requested features in Embedded systems is to avoid, in some way, that the user is "prompted" by the operating system or by an application not designed for the Embedded, to interact with keyboard, mouse or touch.

This situation is well exemplified by the images that follow: it does not only embarrass the user not able to interact, but even if he was able to do so, he may not often know which the right answer is.

We return to talk about the difference between a desktop system, where the user must be aware of being in front of a computer with an operating system and its applications, and an "embedded system" intended as a "dedicated application", in which the user knows to be faced with a product designed and manufactured to meet his own specific needs (e.g. the cash register for a cashier, an information kiosk to get information, etc. ...).

To avoid (or at least minimize) the interaction of the operating system and other applications with the user and to avoid falling into the situations above described, Windows Embedded Standard 7 offers many solutions that, combined together, can limit the user's intervention requests beyond his competence on the applications.

Some of these, such as the ability to respond with a standard response to a Message Box before it is displayed or NOT to display a notification pop-up balloon, were already possible in previous versions (Windows Embedded Standard 2009). Others, like the ability to put a filter on any window that is going to appear so that you can control the new window behavior, have been added in this release.

The MessageBox function of the Windows API provides the programmer the ability to display a dialog box that can contain text, buttons and symbols. This function is typically used to display warnings or errors and to offer the users choices about how to operate in the displayed situation.

With Pop-Up Balloons, we refer to those messages that appear when an application (or the system itself) wants to communicate something about the status of a function as, for example, when you insert a USB key and the system displays a balloon to notify that it has detected a device and it is loading the related driver.

This post is the first in a series of four posts that make an article on user interface filters. In particular, we will deal with:

1. Message Box Default Reply

by using ICE

by using IBW

by using DISM

Let's practice

2. Turn off Pop-Up balloons

3. Dialog box filter

by using ICE

by using IBW

by using DISM

Let's practice

To promote the immediacy of understanding of these features, we report, since this first post, the final conclusions of the article in its entirety will be clearer after reading all the posts.

User interface filters - conclusion

To protect our application from the system messages and from the ones arriving from other applications we can use Message Box Default Reply, turn off the Pop-Up Balloons or appropriately configure the Dialog Box Filter. With the first two solutions we get a global change to the system, with the last one we can improve the granularity of the configuration. This is very effective if we have to surgically neutralize some windows that appear when you do not want to, but it becomes a big job if the number of windows to manage grows up: for example, the buttons text localization could force us to diversify the configuration file according to the language used.

____________________________________

These articles, divided into post, were written, revised and translated into English as well as by me by other two colleagues of mine: Gianni Rosa Gallina (blog) eMVP and Marina Sabetta.

For more information please refer to these links (in English):

http://msdn.microsoft.com/en-us/library/ff793549(v=winembedded.60)

http://msdn.microsoft.com/en-us/library/ff794009(v=winembedded.60).aspx

http://msdn.microsoft.com/en-us/library/ee832759.aspx