(Post 2 di 4)
Questo post è il secondo di una serie di quattro post che
compongono un articolo che tratta l'argomento dei filtri verso
l'interfaccia. In particolare ci occuperemo di:
Risposta standard ai messaggi (Message Box Default Reply)
Configurazione mediante ICE
![clip_image001[1]](/media/1954/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B1%5D_thumb.png)
Configurazione mediante IBW
![clip_image001[2]](/media/1964/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B2%5D_thumb.png)
Installazione mediante DISM
![clip_image001[3]](/media/1974/Windows-Live-Writer_0366d62b304f_14811_clip_image001%5B3%5D_thumb.png)
Esempio pratico
______________________________________________________
Risposta standard ai messaggi (Message Box Default Reply)
Sia il sistema operativo Windows che le applicazioni che girano
in questo ambiente spesso richiedono un'interazione da parte
dell'utilizzatore. Questo può accadere in una situazione di errore:
si vuole attirare l'attenzione dell'utente, anche se non c'è
effettivamente nessuna scelta da compiere; semplicemente, si
conferma di avere letto il messaggio. Può presentarsi invece la
situazione in cui la finestra con la Message box richieda una
scelta e, in questo caso, chi ha preparato il messaggio ha anche
scelto la risposta "standard" (quella cioè dove è posizionato il
"focus" - pulsante attivo) e che viene presa come default: basta
premere Invio per confermarla.
Nel caso dei dispositivi Embedded, come abbiamo evidenziato
all'inizio di questo capitolo, spesso l'utente è ignaro di essere
davanti ad un computer e ad un sistema operativo, quindi NON si
aspetta di dover intervenire su richieste che non sono strettamente
quelle dell'applicativo che sta utilizzando (es: se una cassiera
vedesse una finestra di messaggio che le chiede qualcosa legato al
sistema operativo, chiamerebbe l'assistenza senza continuare il
proprio lavoro).
Il poter intercettare i messaggi di sistema (System Message
Interception) può essere una base per evitare questa situazione.
Per far questo si può sfruttare una proprietà già presente nella
NTUSER.Dll e pilotata da alcune chiavi del registro, ma l'ambiente
di sviluppo ci viene incontro con il configuratore (ICE) che ci
permette in un modo molto semplice di gestire le nostre scelte
senza scrivere una riga di codice.
I messaggi che arrivano a schermo potrebbero essere importanti
sia per l'applicazione che per il sistema; quindi, poterli
ridirigere sul file di LOG del sistema è di fondamentale
importanza. Il file di LOG, che normalmente può essere analizzato
da applicativi di sistema, nel caso di dispositivi Embedded può
essere controllato da un applicativo remoto, automatizzato quanto
basta perché, in caso di segnalazioni che necessitano di un
intervento di un tecnico (es: un disco sta per riempirsi),
quest'ultimo possa intervenire senza interruzioni di servizio.
Prima di tutto, vediamo cosa si può fare: l'obiettivo principale
è non far arrivare a schermo il messaggio, ma gestirlo
correttamente.
Risposta standard ai messaggi (configurazione mediante
ICE)
Dopo aver inserito nella build il package "Message Box Default
Reply" (=MBDR) che si trova tra le "Embedded Enabling Features",
abbiamo a disposizione queste scelte:
EnableDefaultReply Serve
ad abilitare o meno questa funzionalità:
0= disabilitata, la funzione non intercetta nessun
messaggio;
1= abilitata (valore di default), la funzione intercetta tutte le
Message
box e seleziona automaticamente la risposta di
default.
EnableLogging Serve a scegliere se far generare al sistema un
evento per tener traccia della finestra di messaggio nel log degli
eventi:
0= disabilitata, nessun evento viene generato;
1= abilitata (valore di default), viene generato un evento di
sistema in accordo con il valore che viene selezionato nel
parametro LogSeverity.
LogSeverity Serve a scegliere quali tipi di messaggi generare
nel log degli eventi di sistema;
0= memorizza tutti i tipi di messaggi (valore di default);
1= memorizza tutti i messaggi che definiscono i parametri di stile
(dwStyle): MB_USERICON, MB_ICONASTERISK, MB_ICONQUESTION,
MB_ICONEXCLAMATION e MB_ICONHAND;
2= memorizza tutti i messaggi di errore, avvertimento, domanda e
di informazione, mentre i messaggi senza parametri di stile
(dwStyle) o dove lo stile è MB_ICONUSER NON vengono
memorizzati;
3= memorizza tutti i messaggi di errore, di avvertimento e di
domanda. I messaggi di informazione senza parametri di stile
(dwStyle) e quelli che hanno un livello (severity) definito
dall'utente NON vengono memorizzati;
4= memorizza soltanto i messaggi di errore e di
avvertimento;
5= memorizza soltanto i messaggi di errore;
Risposta standard ai messaggi (configurazione mediante
IBW)
Mentre le configurazioni che abbiamo visto possono essere
facilmente effettuate all'interno del Configuratore (ICE),
utilizzando il Wizard (IBW) non è possibile scendere nello stesso
dettaglio. Ci si limiterà ad inserire il package nella build e, a
Run-Time, si interverrà, con le dovute cautele, sulle chiavi di
registro che pilotano questo filtro. Con riferimento alle variabili
di cui sopra, risulta che per abilitare la funzionalità in toto,
bisogna agire sulle variabili della chiave:
HKLM\System\CurrentControlSet\Control\Error Message
Instrument
Riportiamo le chiavi che ci potrebbero interessare con i loro
valori di default risultanti dalla build:
…\Error Message
Instrument\EnableDefaultReply=1
…\Error Message
Instrument\EnableLogging=1
…\Error Message
Instrument\LogSeverity=0
Allo stesso tempo è necesseario configurare le chiavi:
HKLM\System\CurrentControlSet\Services\EventLog\Application\Error
Instrument\ TypesSupported=0x00000007 (REG_DWORD)
e
HKLM\System\CurrentControlSet\Services\EventLog\Application\Error
Instrument\ EventMessageFile=%SystemRoot%\System32\User32.dll
(REG_EXPAND_SIZE)
Note:
· La modifica di queste chiavi, di solito, necessita di un
riavvio della macchina.
· Alcune applicazioni, siano queste di sistema o di terze parti,
NON utilizzano le finestre di messaggio in maniera canonica e
quindi questi POP-UP NON vengono intercettati! In questo caso
bisognerà ricorrere ad altri metodi per evitare che il messaggio
"non voluto" arrivi all'utente.
· Se si sceglie di abilitare questa funzione, lo si fa per TUTTE
le Message box senza poter distinguere ulteriormente.
· Attenzione alle situazioni di "stallo": un applicativo, alla
pressione della X in alto a destra della finestra, mostra una
Message box con una scritta del tipo "Chiudere l'applicazione?" ed
il default sul tasto "SI"; a questo punto, visualizza una seconda
Message box con la scritta "Sei proprio sicuro di voler chiudere?"
ed il default su "NO". In questa situazione, se la funzionalità di
MBDR è abilitata, premendo la X non si riuscirà a chiudere
l'applicazione, poiché entrerà in un ciclo infinito tra le due
Message box!
· Attenzione all'utilizzo di questi filtri con quelli che
proteggono la scrittura su disco. Il consiglio è di disabilitare
tutti i filtri di scrittura su disco, effettuare tutte le prove del
caso fino ad arrivare ad una situazione soddisfacente e solo in
quel momento riabilitare i filtri sui dischi e creare la copia
MASTER del sistema.
Risposta standard ai messaggi (installazione mediante
DISM)
Una delle nuove funzionalità introdotte da questa versione di
Windows Embedded rispetto alle precedenti è la capacità di
aggiungere dei package ad un'immagine di sistema già operativa.
Utilizzando il tool DISM (Deployment Image Servicing and
Management), infatti, si possono eseguire molte operazioni sui
package contenuti nel sistema e, tra queste, l'aggiunta "OnLine"
(cioè su un sistema che sta girando) di singoli package o di intere
"configuration set" (gruppi di package legati tra loro da
dipendenze interne).
Per compiere l'operazione di aggiunta bisogna seguire dei
semplici passi:
1) Controllare che il package che si vuole aggiungere NON abbia
altre dipendenze da package NON inseriti nel sistema;
2) Individuare il nome del package che si vuole inserire e la
sua posizione;
3) Rendere disponibile il package al sistema che si vuole
aggiornare;
4) Eseguire il comando di aggiunta del package "OnLine".
Vediamo come:
1) Supponiamo che l'Answer File di
partenza del nostro sistema sia "Validato", ma che non contenga il
Package "Message Box Default Reply";
a. Si apre il file di costruzione (l'Answer
File di build) del nostro sistema con il
configuratore (ICE);
b. Si aggiunge il package
"\FeaturePack\EmbeddedEnablingFeatures\Message Box Default
Reply";
c. Si esegue la validazione della build;
d. Si salva questa nuova versione dell'Answer
File con un nome diverso dall'originale;
e. Si controlla che le differenze tra i due Answer
File siano soltanto legate all'aggiunta del package
"Message Box Default Reply"; dovrebbero esserci soltanto queste
"cinque" righe:
<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>
2) Il nome del package e il percorso dove si trova il suo file
d'installazione si possono desumere direttamente
dall'Answer File nella riga "source
location":
"%distributionshareroot%\Packages\FeaturePack\x86~winemb-messageboxdefaultreply~~~~6.1.7600.16385~1.0\WinEmb-MessageBoxDefaultReply.cab"
Oppure, nell'ambiente del configuratore (ICE), ci si posiziona
nella colonna centrale dell'Answer File e
si effettua un doppio click sul package Message Box Default
Reply: sulla destra, l'elemento Path del folder
properties ci darà il nome della cartella dove si
trova il package ed il suo nome corretto.
3) Copiamo il file d'installazione (.CAB) in un posto dove
potremo raggiungerlo dal sistema che vogliamo aggiornare (ad
esempio sulla cartella principale di una chiavetta USB).
4) Supponiamo che la chiavetta di cui sopra per il sistema che
vogliamo aggiornare si chiami "E:". Per eseguire il comando:
a. Aprire un prompt di comandi con i diritti di
amministratore;
b. Dare il comando:
dism /online /add-package
/PackagePath:E:\WinEmb-MessageBoxDefaultReply.cab
Il sistema risponderà con una serie di messaggi:
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
poi farà comparire una barra di progressione fatta a caratteri,
che, raggiunto il 100%, si presenterà così:
[==========================100.0%==========================]
The operation completed successfully.
Restart Windows to complete this operation.
Do you want to restart the computer now (Y/N)?
Al riavvio il sistema completerà l'installazione.
Nota: Il package così installato è subito
abilitato all'intercettazione delle Message
Box.
Risposta standard ai messaggi (esempio pratico)
Per meglio comprendere il funzionamento di questo servizio,
abbiamo creato una semplice applicazione .NET, chiamata
Test_1, che visualizza una
Message
box di nome Test con
tre pulsanti: Annulla,
No e Sì
(Sì è la selezione di default) e, a
prescindere dal pulsante premuto, visualizza una finestra, chiamata
Form1, che presenta soltanto un pulsante
con la "stringa" della funzione del pulsante premuto in precedenza;
la prima finestra che compare può essere gestita con la risposta
standard ai messaggi (MBDR) che, se abilitata, avrà l'effetto di
non far apparire la prima finestra: verrà visualizzata direttamente
la seconda con il nome del pulsante a
"Yes", come se avessimo premuto il tasto
Invio sulla prima finestra.
Scendendo nella pratica del nostro esempio, per prima cosa
controlliamo che la chiave di registro per l'abilitazione
dell'intercettazione dei messaggi NON sia abilitata, in modo da
capire come evolve l'applicazione senza filtri. Utilizzando
l'editor del registro di Windows (con diritti di amministratore)
Regedit navighiamo fino alla chiave:
HKLM\System\CurrentControlSet\Control\Error
Message Instrument
E controlliamo che la variabile di abilitazione sia a zero:
EnableDefaultReply=0
Nota: Per poter utilizzare gli applicativi di
amministrazione sul PC-Target, bisogna includere nella build i
pacchetti che li contengono; ad esempio, per
Regedit il pacchetto è:
FeaturePack\Management\System Management\System
Management Utilities.
Per trovare il pacchetto corretto nell'ambiente del
configuratore (ICE), si consiglia di:
• utilizzare la funzione "Find" (Ctrl-F);
• selezionare l'opzione "Search file names in packages";
• cercare "Regedit.exe".
Con un doppio click sulla riga corrispondente ci si ritroverà
già nella colonna della Distribution Share con il package corretto
selezionato.
Lanciamo ora l'applicativo Test_1 ed
otteniamo:
Clicchiamo, ad esempio, il pulsante No nella
Message
box ottenendo;
se clicchiamo su quest'altro pulsante No,
l'applicativo ci ripropone la Message
box iniziale. Si possono provare gli altri
pulsanti della prima maschera oppure chiudere l'applicativo
cliccando sulla X in alto a destra della maschera
Form1.
A questo punto, abilitiamo il servizio in modo che intercetti le
Message
box. Utilizzando l'editor del registro di
Windows (con diritti di amministratore)
Regedit navighiamo fino alla chiave:
HKLM\System\CurrentControlSet\Control\Error
Message Instrument
e modifichiamo la variabile di abilitazione mettendola a uno:
EnableDefaultReply=1
Nota: Questa variazione è recepita quasi
immediatamente dal sistema senza necessitare di altre azioni per
renderla efficace.
Rilanciamo l'applicativo Test_1 ed
otteniamo direttamente:
Proprio come se avessimo premuto il pulsante
Yes,che è la scelta di default.
Se in condizioni normali cliccassimo sul pulsante
Yes, l'applicativo ci riproporrebbe la
Message
box iniziale, ma ora il servizio la
intercetta e non la visualizza, quindi si ritorna alla stessa
maschera; per chiudere l'applicativo clicchiamo
sulla X in alto a destra.
Per controllo, si potrà analizzare il registro degli eventi di
Windows alla voce "Applicazioni": si verificherà che, se si è
abilitata la chiave di registro
EnableLogging, tutte le volte che
un'applicazione visualizza una Message
box viene riportato un evento nei log di
sistema anche se il filtro MBDR ne ha impedito la visualizzazione.
Utilizzando il visualizzatore degli eventi di Windows (con diritti
di amministratore) Eventvwr,
riconosceremo l'evento che ci interessa dall'Origine (=
Error Instrument) e da Data e
ora. Nella cartella "Generale" si possono controllare le
altre informazioni: ProcessName
(=Test_1), MsgCaption (=Test), ecc..
P
____________________________________
Questo post è stato scritto, curato nei particolari oltre che da
me anche da due miei colleghi: Gianni Rosa Gallina (blog)
eMVP e Marina Sabetta.
Per ulteriori informazioni potete riferirVi a questi
collegamenti (in inglese):
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
