Sviluppo di
interfacce utente
Vediamo un semplice modello per lo sviluppo rapido di documentazione e codice di interfacce collegate a dati
ra i molteplici problemi
che affliggono l’analista-
programmatore, quello
che riguarda la progettazione e
lo sviluppo dell’interfaccia uten-
te è spesso il più oneroso.
L’obiettivo di questo articolo è
di fornire una struttura base fa-
cilmente adattabile e che si pre-
sti ad ulteriori “sofisticazioni”
per la creazione di un tool di
generazione automatica di inter-
facce.
LO SCENARIO DI RIFERIMENTO
La grande diffusione di ambien-
ti operativi a finestre, la dispo-
nibilità di tool visuali di sviluppo e la ricca do-
cumentazione che guida nella ricerca di un cor-
retto stile nel dialogo con l’utente non impedi-
scono - il più delle volte - un approccio che
risente ancora della tradizionale impostazione
ASCII-like “unica finestra è lo schermo”.
Spesso, infatti, lo sviluppo di una nuova appli-
cazione si trasforma in un “porting” su un am-
biente operativo a finestre.
È spiacevole, inoltre, assistere anche alla per-
dita delle caratteristiche positive delle vecchie
interfacce; come quando, ad esempio, si obbliga
l’operatore a spostarsi unicamente con il tasto
“Tab” tra un campo e l’altro (quasi che il conse-
guente risparmio di due o tre righe di codice sia
metodo contemplato dalle moderne tecniche di
ingegnerizzazione economica del software!).
L’esempio applicativo che prenderemo in con-
siderazione riguarderà un form di gestione di
un’anagrafe dei soggetti che entrano in contatto
con una ipotetica azienda.
Per soggetti intendiamo quindi: Fornitori, Clienti,
Agenti e genericamente “Altro”. In Figura 1 è
stato riportato lo scenario di riferimento. Le due
modalità d’uso dell’applicazione sono: immissio-
ne di nuovi soggetti tramite wizard o tramite un
classico form di data-entry; gestione di soggetti
in archivio (modifica, stampa, ecc.).
Seppure il codice allegato è riferito al solo form
di gestione dei soggetti per quanto strettamente
Dev. Developing Software & Solutions
visualbasic.PM6 43
di Benedetto Neigre
Benedetto Neigre
ha lavorato come
Scenario di riferimento
system administrator
presso l’Amministra-
zione Provinciale di
L’Aquila.
Attualmente è
impegnato in un
progetto Domino/
Notes presso l’ASL di
Avezzano-Sulmona.
Si interessa anche di
sicurezza, computer
crime, sviluppo VB e
può essere contattato
per email come
bneigre@infomedia.it
necessario a questa esposizione, è opportuna
qualche riflessione riguardo al contesto - più
ampio e complesso - di una ipotetica applicazio-
ne reale.
Ciò che condiziona di più nello sviluppo di una
interfaccia è la preoccupazione dello sviluppa-
tore di fornire uno strumento agile di acquisi-
zione dati. La “soluzione classica” per il data-
entry è quella che prevede l’acquisizione dei dati
su form con avanzamento libero tra campi (con
la pressione del ritorno carrello, del tasto tab o
tramite mouse indifferentemente) e scelta della
validazione dei dati a livello di campo, di form o
mista a seconda delle specifiche esigenze.
Tale modalità è ampiamente consolidata e pre-
vale, come soluzione adottata, nella maggior parte
dei casi, pur essendo utile allo snellimento dei
tempi di immissione dei dati, solo in una ristret-
tissima casistica. A questa modalità si contrap-
pone l’utilizzo del wizard il cui uso è preferibile
ed auspicabile in quanto permette una maggiore
concentrazione dell’operatore sui singoli step di
lavoro ed evita errori che determinano un dete-
rioramento dei tempi di immissione delle infor-
mazioni.
In linea di massima, nei wizard correttamente
progettati, ad un dato da acquisire deve corri-
spondere una modalità preferenziale da usare (ta-
stiera o mouse) al contrario delle form di data-
entry classico che spesso obbligano ad interve-
43 Numero 82 - Febbraio 2001
18/01/01, 16.16
 nire in vari modi e in punti diversi del form stes-
so (TextBox, DataCombo, OptionBox, CheckBox). Form frmRicerca utilizzato per acce-
dere a frmSoggetti
Ferma restando la possibilità di far convivere
wizard e modalità “classica” per l’acquisizione dati,
vogliamo porre l’attenzione su un modello di ge-
stione della nostra interfaccia che consenta di otte-
nere un rilevante abbattimento dei tempi di svilup-
po, non rinunciando alle peculiarità di un ambiente
operativo a finestre e senza cedere a scorciatoie
che, come detto, trasformino la nostra applicazio-
ne in un banale “porting”. Lo strumento di coman-
do scelto è una ToolBar: ai controlli che serviranno
a presentare le informazioni all’utente saranno as-
segnati dei “codici colore” che identificheranno lo
status del campo.
Contrariamente a quanto si potrebbe pensare, per
il collegamento dei controlli ai campi non verranno
utilizzate le proprietà tipiche dei controlli stessi -
come in [1], [2] o nelle creazioni guidate del VB -
ma si ricorrerà allo SQL cablato nel codice.
Il lavoro descritto, incentrato sul form frmSoggetti,
tende a standardizzare quanto più possibile il lega-
me tra rappresentazione a video e DB.

IL FORM D’ESEMPIO
Per l’accesso a frmSoggetti utilizzeremo una sem-
plice maschera di passaggio, frmRicerca in Figura 2,
che ci consentirà di ricercare il soggetto di nostro
interesse.
Il codice che gestisce il passaggio alla frmSoggetti è
quello riportato nel Listato 1 e la routine di acces-
so ai dati del soggetto è LeggiSoggetto(CodiceSoggetto
as String) di frmSoggetti.
A margine è opportuno evidenziare un utile mec-
canismo, sempre presente in Listato 1 (al commento
Salvataggio delle opzioni di ricerca), per il mantenimen-
to dei valori immessi dall’utente in fase di ricerca. I
valori indicati sono passati al Tag del form frmSog-
getti come stringa sfruttando il “punto e virgola”
come separatore.
Le scelte operate nella
progettazione dell’interfaccia
permettono una netta
separazione tra contesto
di visualizzazione
e contesto di modifica
In Figura 3 è stato riportato il form frmSoggetti,
la ToolBar viene gestita da codice al fine di adat-
tarsi al contesto operativo.
Nella sezione “Generale - Dichiarazioni” viene
dichiarata una variabile booleana InModifica che
servirà ad evitare l’attivazione dello stato di mo-
difica per più di un campo alla volta.
Sempre in questa sezione vengono dichiarati i
necessari oggetti recordset per le DBCombo; in
alternativa è possibile limitare il ciclo di vita di
questi oggetti al solo spazio elaborativo richiesto
per l’operazione di modifica dello specifico cam-
po, migliorando così la velocità di accesso al re-
cord del soggetto. Per la rappresentazione dei dati
in archivio vengono utilizzate delle TextBox con:
proprietà Name, di norma, impostata a txt-
NomeCampo (dove NomeCampo è il nome del
campo nella tabella del DB);
proprietà Locked = True;
colore di fondo grigio per indicare la possibilità
di modificare il valore;
colore di fondo bianco per indicare che si è in
modalità di modifica;
colore di fondo giallo chiaro per indicare l’im-
possibilità di modificare il valore;
colore di fondo arancione per indicare la possi-
bilità di selezione di un nuovo valore che deter-
mina un cambio di record (Es. x CodiceSoggetto).
Nel caso che il campo da visualizzare a video
sia derivato da un’altra tabella di DB (relazione
tramite chiave esterna) sarà presente, in corrispon-
denza della TextBox visibile (ospitante il valore
contenuto nel campo correlato), un controllo
DataCombo nascosto e associato tramite codice.
Le operazioni di modifica dei dati vengono atti-
vate dall’operatore tramite doppio clic sul campo
di interesse; il software provvede a modificare il
colore di fondo della TextBox interessata alla
modifica o a rendere visibile il DataCombo relati-
vo nascondendo la TextBox.
La scelta della modifica dei colori, la modifica
delle opzioni della ToolBar, la disponibilità trami-
te doppio clic e non tramite un semplice trasferi-
mento del focus (a qualunque titolo) permettono
una netta separazione tra contesto di visualizza-
zione e contesto di modifica, consentendo all’ope-
ratore una maggiore consapevolezza ed un pieno

Dev. Developing Software & Solutions 44 Numero 82 - Febbraio 2001

visualbasic.PM6 44 18/01/01, 16.17

 Codice di gestione del passaggio Routine di intercettazione delle ri-
da frmRicerca a frmSoggetti chieste di ingresso nello stato di
modifica del campo

Private Sub lsvRubrica_DblClick() Sub DblClkCampo(Ctl As Control)

If Me.lsvRubrica.ListItems.Count > 0 Then Dim Found As Boolean
If Me.lsvRubrica.SelectedItem.Text “” Then Dim MyObject As Control
Load frmSoggetti If Not InModifica Then
With frmSoggetti ‘Verifico l’esistenza di un DataCombo corrispondente
.LeggiSoggetto Mid$(lsvRubrica.SelectedItem.Key, 3) ‘al controllo TextBox (verifico se ci sono dati correlati)
.Show Found = False
.Enabled = True For Each MyObject In Me.Controls
.SetFocus If MyObject.Name = “dbc” & Mid$(Ctl.Name, 4) Then
.Tag = cmbTipo.Text & “;” Found = True
‘Salvataggio delle opzioni di ricerca Exit For
End If
If optRaSocNote(0) = True Then
Next
.Tag = frmSoggetti.Tag & “0;”
InModifica = True
Else
InizializzaToolBar Mid$(Ctl.Name, 4)
.Tag = frmSoggetti.Tag & “1;”
If TypeName(Ctl) = “TextBox” And Not Found Then
End If
Il campo non ha collegamenti in altra tabella
.Tag = .Tag & txtCerca.Text
With Ctl
Unload Me
Temp = .Text
End With
.BackColor = &H80000005
End If
.Locked = False
End If
.SelStart = 0
End Sub .SelLength = Len(.Text)
.SetFocus
End With
Else
controllo.
‘Il controllo contiene un valore di collegamento
Da questo momento, se non diversamente spe-
in altra tabella
cificato, tratteremo unicamente di frmSoggetti poi- ‘abilito il DataCombo per i dati collegati
ché il codice di frmRicerca (che è comunque alle- Temp = Ctl.Text
gato) non è “centrale” rispetto all’argomento trat- Ctl.Visible = False
tato. Controls(“dbc” & Mid$(Ctl.Name, 4)).Visible = True
L’evento Form_Load contiene solo il necessario al- Controls(“dbc” & Mid$(Ctl.Name, 4)).Text = Ctl.Text
l’inizializzazione degli oggetti recordset per le DB- End If
Combo e alla ListView. End If
La ToolBar viene gestita tramite la routine End Sub
InizializzaToolBar(OP as String) in cui la variabile pas-
sata identifica il set di comandi da rendere disponi-
bili. In linea di massima avremo una impostazione Allo stesso modo, Commerciale e Classe (chiavi per
predefinita (per OP pari a “Inizializza”), eventuali la relazione con la tabella Soggetti la prima e con
impostazioni accessorie ed un numero n di impo- la tabella Classificazioni la seconda) necessiteran-
stazioni pari al numero di campi da trattare, rag- no, dopo il passaggio allo stato di modifica, dei
gruppati per tipologia di comandi disponibili. comandi “Nuovo”, “Conferma”, “Annulla” po-
Come esempio prendiamo in considerazione i tendo così essere raggruppati.
campi Indirizzo, Note, Commerciale, Classe: Al termine delle impostazioni della ToolBar viene
anche assegnato il valore di OP al Tag del coman-
do “Annulla”, disponibile sulla ToolBar stessa in
Ai controlli che serviranno modo da poter gestire i successivi eventi correlati
al campo (tbrMagArt.Buttons.Item(“Annulla”).Tag = Op).
a presentare le informazioni Per “impostazioni accessorie” si intendono quelle
all’utente saranno assegnati relative, ad esempio, alla scheda “Prodotti” della
dei “codici colore” che SSTab la cui attivazione (passaggio del focus) do-
identificheranno lo status vrebbe determinare un cambiamento dei bottoni
del campo della ToolBar, al fine di consentire la gestione
dell’elenco prodotti trattati dal soggetto (nel caso
la Classe Soggetto sia, ad es., “Fornitori”).
Ricapitolando: la modifica richiesta dall’utente
se l’operatore richiede la modifica del campo In- su campi rappresentati da OptionBox o da Che-
dirizzo (txtIndirizzo sul form) oltre ad intervenire ckBox sarà diretta ed implementata, quindi, nella
sulla relativa TextBox dovremo modificare i co- routine relativa all’evento; utilizzeremo invece una
mandi della ToolBar permettendo all’operatore i chiamata alla routine in Listato 2 in tutti gli altri
fondamentali “Conferma” e “Annulla”; identici casi. Al termine delle procedure appena descrit-
comandi dovranno essere disponibili quando si te, il software si troverà in stato di attesa di un
andrà in modifica del campo Note. comando (Nuovo se richiesto dal contesto, Confer-

Dev. Developing Software & Solutions 45 Numero 82 - Febbraio 2001

visualbasic.PM6 45 18/01/01, 16.17

 ma o Annulla).
La routine di intercettazione Form frmSoggetti

del comando selezionato sulla

ToolBar demanda la gestione
della conferma delle modifiche
operate sul campo alla routine
“ConfermaModifiche” in cui vie-
ne esaminato il valore di
tbrMagArt.Buttons.Item(“Annulla”).Tag
Nei wizard per deter minare il corretto
correttamente
progettati, ad un
blocco-operazioni da eseguire.
dato da acquisire Come si vede dalle poche ri-
deve corrispondere ghe di codice riportate di se-
una modalità guito anche in questa sede è
preferenziale da
possibile operare dei raggrup-
usare, tastiera o
mouse, da parte
pamenti in base alle “affinità”
dell’utente. dei campi da gestire.

Case Is = “Note”, “Indirizzo”, “CAP”, “Citta”

‘…seguono altri
ModificaCampo
tbrMagArt.Buttons.Item(“Annulla”).Tag,_
Me.Controls(“txt” & _
tbrMagArt.Buttons.Item(“Annulla”).Tag).Text
Me.Controls(“txt” & _
tbrMagArt.Buttons.Item(“Annulla”).Tag).BackColor
= 14737632
Me.Controls(“txt” & _
tbrMagArt.Buttons.Item(“Annulla”).Tag).Locked
= True
Per l’annullamento dell’operazio-
ne, così come per la conferma
delle modifiche, si provvederà a
trattare il campo tramite l’insie-
me controls sfruttando la possibili-
tà di assemblare il nome del con-
trollo utilizzando i prefissi e il
valore che abbiamo ereditato tra-
mite la proprietà Tag del button
Annulla della ToolBar. In Lista-
to 3 è riportata la parte di codice
della procedura di annullamento
appena citata.
A modifiche apportate (routine
ModificaCampo(Campo As String,
Valore As Variant)), si procede ad
una nuova lettura del soggetto tra-
mite LeggiSoggetto(CodiceSoggetto as
String) di frmSoggetti in modo da
evitare ogni ulteriore complica-
zione legata ad aggiornamento di
campi correlati multipli.
LA DOCUMENTAZIONE DI
SUPPORTO
Una volta acquisita la logica di
funzionamento, possiamo prende-
re in considerazione i passi fon-
damentali che ci aiuteranno nel
definire una nuova interfaccia.
Con l’aiuto di un foglio elettroni-
co prepariamo una tabella com-
posta dalle seguenti colonne:
1. campi della tabella di DB da
rappresentare;
2. tipo di dati del campo con
specifica della lunghezza mas-
sima per i tipi stringa;
3. ammissibilità del valore Null;
4. valore di default per il cam-
po;
5. eventuale tipo di collegamen-
to ad altra tabella, colore di
fondo della cella corrispon-
dente allo standard fissato
per la rappresentazione a vi-
deo per i campi (giallo = non
modificabile; grigio = modi-
ficabile, ecc.);
Possiamo
“assemblare”
tutto il codice
necessario alla
gestione del nostro
form in pochissimi
minuti
6. eventuale validazione delle
modifiche apportate;
7. eventuale tabella correlata;
8. campo chiave riferito al pun-
to 7;
9. elenco campi dati riferito al
punto 7;
10. nome dell’oggetto, sul form,
che rappresenterà il campo (di
norma l’estensione standard
dell’oggetto seguita dal nome
del campo in tabella).
Dalla colonna 11 si comincia-
no a riportare i comandi della To-
olBar necessari a gestire corret-
tamente la rappresentazione del
campo.
Con questa semplice schematiz-
zazione possiamo “assemblare”
tutto il codice necessario alla ge-
stione del nostro form in pochis-
simi minuti.
Lo standard adottato, come già
detto, prevede che in presenza di
dati correlati siano presenti una
TextBox e un DataCombo con il
nome del campo chiave e n Tex-
tBox per gli eventuali altri campi
correlati.
L’aggiornamento delle infor-
mazioni sul form è sempre de-
mandato alla routine di lettura
del record tramite l’utilizzazio-
ne della chiave univoca della ta-
bella da rappresentare (nel no-
stro caso LeggiSoggetto(CodiceSog-
getto as String)) al fine di evitare
codice addizionale per l’eventua-
le “sincronizzazione” di altri dati
correlati.
Questa modalità di azione ci con-
sente, inoltre, di mantenere una
maggiore standardizzazione del
codice. La presenza di eventuali
indicazioni nella colonna 6 indi-
ca la necessità di gestire il cam-
po senza aggregazione con altri
a causa delle peculiarità descrit-
te (ad esempio nel caso di un
codice univoco la cui assenza in
archivio debba essere verificata
preventivamente).
Si dovrà necessariamente evi-
tare l’aggregazione anche per

Dev. Developing Software & Solutions 46 Numero 82 - Febbraio 2001

visualbasic.PM6 46 18/01/01, 16.17

 generazione del codice per richie-
Routine di annullamento delle modifiche
ste di conferma modifica su campi
particolari, la verifica preventiva
di date condizioni, la lettura dei
dati per l’aggiornamento a video,
Case Is = “Annulla” il frazionamento di campi su tab-
InModifica = False bed dialog, il wizard di acquisizione
Select Case tbrMagArt.Buttons.Item(“Annulla”).Tag
dati, ecc.. Un ottimo esempio che
Case Is = “Indirizzo”, “Note”, “CAP”, “Citta”, “PartitaIVA”, “Provincia”, _
“Telefono1”, “Telefono2”, “TeleFax”, “EMail”, “WWW”
opportunamente adattato permet-
Me.Controls(“txt” & tbrMagArt.Buttons.Item(“Annulla”).Tag).Text = Temp
terebbe la realizzazione di questo
Me.Controls(“txt” & tbrMagArt.Buttons.Item(“Annulla”).Tag).BackColor = 14737632 strumento lo troviamo in [1].
Me.Controls(“txt” & tbrMagArt.Buttons.Item(“Annulla”).Tag).Locked = True
CONCLUSIONI
Case Is = “Commerciale” L’evoluzione del VB consente,
Me.Controls(“txt” & tbrMagArt.Buttons.Item(“Annulla”).Tag).Visible = True adottando diversi stratagemmi, di
Me.Controls(“dbc” & tbrMagArt.Buttons.Item(“Annulla”).Tag).Visible = False costruire GUI che siano vera-
mente tali senza rinunciare, quin-
Case Is = “RagioneSociale”
di, agli indispensabili requisiti di
txtRagioneSociale.Visible = False
“look” & “feel”.
End Select
La necessità di abbattere tempi
InizializzaToolBar (“Inizializza”)
e costi nello sviluppo del softwa-
re non può certamente passare
attraverso una “creazione guida-
ta” che, se usata, ci ricompense-
quei campi che si vogliono gesti- In ogni caso il massimo cui si rà con un maggiore onere nella
re con controlli particolari come potrebbe aspirare è uno stru- fase di addestramento dell’uten-
ad esempio il campo RagioneSo- mento che a partire dalle speci- za e nella successive inevitabili
ciale che ho assegnato alla Caption fiche di progettazione provveda “customizzazioni” richieste dal-
del frame frameDescrizione. a generare automaticamente il ne- l’utenza stessa. Il tentativo ope-
cessario codice ed il relativo rato è quello di spezzare la du-
POSSIBILI SVILUPPI E NOTE form, magari attingendo ad un plice funzione di una interfac-
Se nello sviluppo di una appli- buon archivio di template. cia orientata a dati nelle due
cazione si è orientati verso l’uso È sottintesa la necessità di un componenti fondamentali:
delle ToolBar e si intende fornire buon approfondimento nell’ana-
qualcosa di più di una semplice lisi con conseguente correzione di il data-entry che viene affida-
interfaccia da “creazione guida- alcune scelte operate dal sotto- to ad un wizard;
ta”, il modello proposto, già in scritto. Una delle modifiche im- la gestione dei dati affidata al
questa forma, risolve svariati pro- mediate è, ad esempio, quella che form sopra descritto.
blemi e permette un drastico ta- riguarda il passaggio del parame-
glio dei tempi di sviluppo. tro di identificazione del campo Rimane chiara la possibilità di
In una applicazione reale dovre- tramite la proprietà Tag del but- operare sul form di gestione an-
mo utilizzare estensivamente al- ton “Annulla” della ToolBar. che come data-entry, aggiungen-
cuni accorgimenti non presenti do una variabile di modulo e adat-
nel form di esempio: tando le routine evento senza per-
Il tentativo dere in generalizzazione. In que-
1. Tool Tip Text, i suggerimenti operato è quello sto modo, pur se in misura mino-
che compaiono quando l’uten- di spezzare la re, avremo comunque operato
te “sosta” con il puntatore del duplice funzione una divisione concettuale ed ope-
mouse su un oggetto; di una interfaccia rativa tra le due modalità.
2. Le shortcut da tastiera, combi- orientata a dati Per quanti iniziano oggi ad af-
nazioni di tasti (massimo due) frontare le problematiche connes-
o “tasti funzione”; nelle due se allo sviluppo di interfacce è
3. Il bottone “Modifica” sulla Tool- componenti consigliabile la lettura di [3] che
Bar, che permetta all’utente una fondamentali introduce abilmente gli elementi
alternativa “visibile” per l’ingres- fondamentali e offre un sapiente
so in modifica (l’uso della pro- Sarebbe infatti opportuno asse- condensato di consigli.
prietà Locked ci consente di in- gnare il valore al Tag del primo
tercettare i tasti tramite l’even- bottone in modo da svincolarlo BIBLIOGRAFIA
to KeyPress di ogni TextBox, po- dalla necessità di avere, appunto, [1] S. Castelli, “Un generatore di
tendo quindi gestire con accu- un bottone “Annulla” sulla ToolBar form”, 1997, Visual Basic Jour-
ratezza ogni “movimento” del stessa. Le possibilità di automazio- nal n. 18.
nostro ipotetico utente); ne del processo sono enormi e [2] M.C. Amudsen, “Creare al volo
4. La funzione di “Undo”, che consentirebbero, se implementate, form in VB”, 1996, Visual Ba-
permetta il recupero di quelli di disporre di uno strumento “de- sic Journal n. 10.
che, vista l’implementazione, finitivo” ed altamente configura- [3] C. Pescio, “Interfaccia Utente ”,
dovrebbero essere rari errori. bile che dovrebbe includere la Computer Programming n. 45.

Dev. Developing Software & Solutions 47 Numero 82 - Febbraio 2001

visualbasic.PM6 47 18/01/01, 16.17