(Post 2 of 4)
This post is the second in a series of four posts that make an
article on user interface filters. In particular, we will deal
with:
Message Box Default Reply
by using ICE
![clip_image001[1]](/media/1908/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B1%5D_thumb.gif)
by using IBW
![clip_image001[2]](/media/1918/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B2%5D_thumb.gif)
by using DISM
![clip_image001[3]](/media/1928/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B3%5D_thumb.gif)
Let's practice
______________________________________________________
Message Box Default Reply
Both the Windows operating system and the applications running
in this environment often require user's interactions. This can
happen in error situations: they want to attract the user's
attention even though there is really no choice to be made, just to
confirm that message has been read. When the Message
Box requires a choice, the programmer who prepared
the message had also chosen the default answer (that is the button
where the "focus" will be positioned, the active button): just
press the Return key to confirm it.
In the case of Embedded devices, as we pointed out earlier in
this chapter, the user is often unaware of being in front of a
computer and an operating system, so he does NOT expect to answer
on requests that are not strictly those of the application he is
using (e.g. if a cashier saw a Message
Box that asks something related to the operating
system, she immediately would call the support service without
having the ability to continue her own job).
Being able to intercept system messages (System Message
Interception) can be a starting point to avoid this situation. To
do this you can use some properties already present in NTUSER.dll
and driven by some registry keys. The Windows Embedded Standard 7
Toolkit, however, allows us to manage our own choices in a simple
way without writing a line of code, only by using the Image
Configuration Editor (ICE).
The messages that arrive on the screen may be important for both
the application and the system and then redirecting them to the
system event LOG file is of fundamental importance. The event LOG
file, which can be usually analyzed by a system application, in the
case of Embedded devices can be controlled by a remote application,
automated enough so that, in the case of messages that need an
intervention of a support service (e.g. a disk is going to fill
up), these can occur without interruption of service.
First of all let's see what we can do: the main objective is to
not display the message, but to manage it in the proper way.
Message Box Default Reply (by using ICE)
The "Message Box Default Reply" (MBDR) package is
located inside the "Embedded Enabling Features". After adding the
MBDR package in the build, we have these choices:
EnableDefaultReply specifies whether the Message Box Default
Reply message blocking option is active:
0= inactive, the Message Box Default Reply message
blocking option is inactive;
1= active (default value), the Message Box Default Reply
message blocking option intercepts every MessageBox function and
automatically chooses the default response.
EnableLogging specifies whether information about the
Message Box events is sent to the event
log:
0= disabled, no information is sent to the event log;
1= enabled (default value), the Message box event information is
sent to the log and filtered according to the value of the
LogSeverity property.
LogSeverity specifies the type of Message
Box events that Windows Embedded Standard 7 writes to
the event log:
0= log all Message Box events (default
value);
1= log all Message Box events that
define the dwStyle parameter, including MB_USERICON,
MB_ICONASTERISK, MB_ICONQUESTION, MB_ICONEXCLAMATION, and
MB_ICONHAND.
2= log Message Box events for errors,
warnings, questions, and information. Message
Box events that have no dwStyle parameter or where
the value of dwStyle is MB_ICONUSER are not logged.
3= log Message Box events for errors,
warnings, and questions. Information events, events that have no
dwStyle parameter, and events that have user-defined severity
levels are not logged.
4= log only error and warning Message
Box events.
5= log only error Message Box
events.
Message Box Default Reply (by using IBW)
Even if the configurations that we have seen can be easily made
in the Configurator (ICE), by using the Wizard (IBW), it is not
possible to enter in the same detail. We have only to include the
MBDR package in the build, and "at run time", we will operate, with
due care, on the registry keys that drive this filter. With
reference to the above variables we have that, to full enable the
feature, you must act on the key variables:
HKLM\System\CurrentControlSet\\Control\Error
Message Instrument
Here are the keys that may be of interest with their default
values resulting from the build:
…\Error Message
Instrument\EnableDefaultReply=1
…\Error Message
Instrument\EnableLogging=1
…\Error Message
Instrument\LogSeverity=0
At the same time we have to set two more keys that are
automatically set by ICE:
HKLM\System\CurrentControlSet\Services\EventLog\Application\Error
Instrument\ TypesSupported=0x00000007 (REG_DWORD)
and
HKLM\System\CurrentControlSet\Services\EventLog\Application\Error
Instrument\ EventMessageFile=%SystemRoot%\System32\User32.dll
(REG_EXPAND_SIZE)
NOTE:
These changes usually require a device
reboot;
Some applications, whether they are system or third
party, do NOT use Message Boxes in a standard way and therefore
these POP-UPs will NOT be intercepted! In this case we must rely on
other methods to prevent the "not wanted" message from being
displayed to the user.
If you choose to enable this feature, the filter will be
active for ALL the Message Boxes, without any further
distinction.
Pay attention to "dead lock" situations: at the click on
the upper right X the application displays a Message Box with a
text such as "Close the application?", the default button is "Yes"
and, at this point, it displays a second Message Box that says "Are
you sure you want to close?" and the default choice is "NO"! In
this situation, if the MBDR feature is enabled, pressing X, the
application will not be able to close itself and it will enter in
an infinite loop between the two Message Boxes!
Pay attention to the use, in the same build, of these
filters and those that protect the disk (Enhanced Write Filter and
File Based Write Filter). The advice is to disable all "write"
filters, perform all necessary tests to obtain a satisfactory
situation and only then re-enable the "write" filter and create the
MASTER copy of the system.
Message Box Default Reply (by using DISM)
One of the new features introduced in this version of Windows
Embedded compared to the previous is the ability to add packages to
a system image already built. Using the tool DISM (Deployment Image
Servicing and Management), in fact, you can perform many operations
on the packages and, among these, the addition "OnLine" (directly
on a running system) of individual packages or of entire
"configuration set" (package groups linked by internal
dependencies).
To obtain this adding operation, follow these simple steps:
1) Check that the package you want to add does NOT have
dependencies on other packages NOT included in the system;
2) Locate the name and the path of the package that you want to
add;
3) Make the package available to the system you want to
update;
4) Run the command to add the package "OnLine".
Let's understand how:
1) Suppose that the original Answer
File of our system has been "Validated", but it did
not contain the Package " Message Box Default Reply ":
2) The package name and its path can be inferred directly from
the Answer File in the line "source
location":
"%distributionshareroot%\Packages\FeaturePack\x86~winemb-messageboxdefaultreply~~~~6.1.7600.16385~1.0\WinEmb-MessageBoxDefaultReply.cab"
a. Open the original Answer File of
our system with the configurator (ICE);
b. Add the package
"\FeaturePack\EmbeddedEnablingFeatures\Message Box Default
Reply";
c. Run the validation of the build;
d. Save this new version of the Answer
File with a different name;
e. Check that the differences between the two are only related
to the addition of the package " Message Box Default Reply
" to the Answer File. There should be
only these "five" lines:
<package action="install">
<assemblyIdentity name="WinEmb-MessageBoxDefaultReply"
version="6.1.7600.16385" processorArchitecture="x86"
publicKeyToken="31bf3856ad364e35" language="neutral"
versionScope="nonSxS" />
<source
location=
"%distributionshareroot%\Packages\FeaturePack\x86~winemb-messageboxdefaultreply~~~~6.1.7600.16385~1.0\WinEmb-MessageBoxDefaultReply.cab"
/>
<ew:packageInfo releaseType="Feature Pack"
customInfoVersion="1.0" />
</package>
Or, in the configurator (ICE):
f. move in the middle column (Answer
File);
g. double-click on the package Message Box Default
Reply; on the right panel, the Path element
of the folder Properties will give us the name of
the folder where is the package and its correct name are.
3) Copy the installation file (. CAB) in a place where it can be
reached by the system we want to update (for example, the root
folder of a USB-Key).
4) Suppose that the USB-key above for the system we want to
update is called "E:"
a. Open a command prompt with administrator rights and give the
following command:
dism /online /add-package
/PackagePath:E:\WinEmb-MessageBoxDefaultReply.cab
The system answers:
Deployment Image Servicing and Management tool
Version: 6.1.7600.16385
Image Version: 6.1.7601.17514
Processing 1 of 1 - Adding package
WinEmb-MessageBoxDefaultReply~31bf3856ad364e3
5~x86~~6.1.7600.16385
A progression bar appears:
[==========================100.0%==========================]
The operation completed successfully.
Restart Windows to complete this operation.
Do you want to restart the computer now (Y/N)?
When the system restarts, it will complete the installation.
NOTE: If you install the package in this way it
will be right-now active and all the Message
Box will be intercepted.
Message Box Default Reply (Let's practice)
To better understand the operation of this service, we have
created a simple .NET application, called Test_1,
that displays a Message Box named
Test with three buttons: Yes,
No and Cancel
(Yes is the default selection) and,
regardless of button pressed, it displays a second window, called
Form1 that has only one button with the same text
of the button pressed before: the first window that appears can be
managed with the Message Box Default Reply (MBDR) which,
if enabled, will not display the first window, and will go directly
to the second one with the text of the button to
"Yes", as if we had pressed the Return
key on the first window.
Let's go down to the practice of our example. First, check that
the registry key to enable the message interception is NOT enabled,
in order to understand how the application evolves without filters.
Use the registry editor (Regedit with
administrator privileges) and navigate to the key:
HKLM\System\CurrentControlSet\Control\Error
Message Instrument
set to Zero the value of the enabling filter variable:
EnableDefaultReply=0
NOTE: to use the Administrative Tools on the
PC-Target, the packages that contain them must be included in the
build, such as for "Regedit.exe", the package
is:
FeaturePack\Management\System Management\System
Management Utilities.
To find the correct package inside the configurator
(ICE) you should:
• use the "Find" (Ctrl-F) function;
• select the option "Search file names in packages";
• search for "Regedit.exe".
With a double click on the row, you will be moved to the column
of the Distribution Share with the correct package selected.
Run Test_1 application and you will
obtain:
Click on the No button in the
Message Box and you will obtain:
if you click the No button the application
proposes the first Message Box again. You
can try the other buttons on the first screen or close the
application by clicking on the X in the upper right corner of the
Form1 form.
Now we enable the service to intercept the Message
Boxes. Use the registry editor
(Regedit with administrator privileges) and
navigate to the key:
HKLM\System\CurrentControlSet\Control\Error
Message Instrument
set to one the value of the enabling filter
variable: EnableDefaultReply=1
NOTE: this change is implemented almost
immediately by the system without needing other actions to make it
effective.
Run again Test_1 application and you
will obtain directly:
Just as if we had pressed the button Yes that
is the default choice.
If we click again on the Yes button, the application would
re-display the first Message Box,
but the service
intercepts it and then returns to the same form. To
close the application click the X at top right.
To check if the filter is working, you can analyze the event log
in "Windows Logs" under "Application" and you will verify that, if
you have enabled the EnableLogging
registry key, whenever an application displays a
Message Box, an event is registered in
the system log even if the filter MBDR has prevented the display.
Use the event viewer of windows (Eventvwr with
administrator privileges) recognizing the event
(Source=ErrorInstrument) and check for Date&time. In the
General folder you will double check by using the process name (=
Test_1):
____________________________________
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
