|
Il
primo punto da analizzare è la creazione dell'oggetto
'Applicazione Word', che corrisponde ad una nuova sessione
dello stesso. Si desidera creare un programma che apra Word
e visualizzi un certo testo all'interno di un nuovo documento.
Risulterebbe immediato a questo punto, includere nel progetto
la libreria Word (MSWORDnumeroversione.OLB) corrispondente
alla versione posseduta.
Ma cosa accadrebbe se, esportando l'applicazione, ci si trovasse
di fronte ad una versione di Word inferiore? E come superare
questo primo scoglio?
Il risultato di questa mancanza può essere agevolmente
valutato nell'esempio che segue. Studiandone quindi una piccola
variazione si giungerà alla conclusione che risolverà
la questione.
| Differenti
modi di creare lo stesso oggetto |
La
creazione di un oggetto può essere operata in molteplici
modi. Il primo e più immediato, come già visto,
consiste nell'importare la libreria Word nel progetto. Una
volta fatta riconoscere a Visual Basic la classe con la quale
si desidera operare, sarà un gioco da ragazzi andare
a dichiarare e successivamente definire i diversi oggetti
di cui si compone la libreria. Se ad esempio si dispone della
Microsoft Word 8.0 Object Library, il seguente codice:
Dim
appWord As Word.Application
Dim docWord As
Word.Document
Dim dlgWord As
Word.Dialog |
non
fa altro che dichiarare rispettivamente una nuova sessione di
lavoro Word 8, un documento ed una finestra di dialogo della
medesima classe di oggetti.
Grosso vantaggio di tale soluzione è la disponibilità
dell'Intellisense che permette di ridurre sensibilmente il carico
di lavoro dal momento che fornisce in tempo reale proprietà
e metodi di ogni singolo oggetto. Una volta avviato il progetto
su un PC recante una differente versione di Office si otterrà
però l'errore "Impossibile creare il componente
ActiveX." ossia il famigerato errore 429 che affligge spesso
anche gli sviluppatori VBScript.
Si consideri adesso il seguente codice:
Dim
appWord As Object
appWord = CreateObject("Word.Application.8") |
Il
risultato è esattamente lo stesso a cui portava il blocco
di codice precedente. L'unica differenza nonché l'unico
passo in avanti verso l'indipendenza da qualisiasi vincolo di
versione sta nel fatto che in questa soluzione non rende più
necessario il riferimento alla libreria Word.
Si controlli adesso la versione di Word installata sul proprio
PC e si sostituisca al numero otto un numero inferiore a tale
versione.
Word cercherà di creare un oggetto che in realtà
non esiste sulla propria macchina. Si otterrà anche questa
volta l'errore "Impossibile creare il componente ActiveX."
Per fortuna però il secondo errore è stato espressamente
ricercato e quindi è intenzionale: è bastato indicare
una versione di Word differente da quella installata per generarlo.
Risulta pertanto semplice comprendere che il metodo migliore
per ovviare a questo primo ostacolo è proprio quello
di generalizzare il più possibile, lasciando a Visual
Basic il compito di riconoscere la versione di Word installata:
Dim
appWord As Object
AppWord = CreateObject("Word.Application") |
| I
modelli, i documenti e le funzioni |
In
MS Word le principali attività che possono essere eseguite
dall'utente (salvataggio di un file, chiusura di una finestra
o dell'applicazione e così via) sono generate da funzioni
predefinite.
Tali funzioni sono scritte in VBA e risiedono per impostazione
predefinita nel modello principale Normal.dot.
A tale proposito occorre specificare il rapporto tra Normal.dot
e qualsiasi altro documento aperto da Word.
Quando infatti si genera un nuovo documento, si crea un foglio
di lavoro con determinate caratteristiche: un certo tipo di
visualizzazione, una certa lista di macro e così via.
Ma come fa Word a capire come impostare un documento alla sua
apertura?
Le caratteristiche del nuovo documento vengono importate dal
modello Normal.dot, nel caso in cui il documento utilizzi tale
modello come predefinito. In Windows 2000 la directory contenente
tutti i modelli di Word è C:\Documents and Settings\Administrator\Dati
applicazioni\Microsoft\Modelli.
La presenza di un template predefinito (il modello Normal di
cui si parlava poco fa) permette di eseguire qualsiasi modifica
al documento appena aperto senza che queste siano rese permanenti
al salvataggio.
Si prenda il caso di una macro dannosa per l'applicazione, generata
tramite l'editor di codice VBA di un documento creato dall'utente
e salvato su hard disk con il nome di Documento1.
Se tutti i documenti venissero aperti sul modello dell'ultimo
file salvato, la macro si propagherebbe su tutte le sessioni
di lavoro di Word successive al salvataggio di tale file.
La presenza di un modello predefinito permette pertanto di avere
uno stampo "pulito" dal quale generare una serie di
documenti altrettanto privi di qualsiasi contaminazione.
Il problema nasce quando la macro dannosa di cui si palava poco
prima passa da un documento qualsiasi al template Normal.dot,
e questo passaggio rappresenta l'innesco della carica distruttiva
che si portano dietro i virus delle macro.
Si
è parlato all'inizio del paragrafo di funzioni predefinite,
ossia una serie di macro richiamate dall'applicazione Word
in corrispondenza di eventi generati dall'utente.
La lista è consultabile da un qualsiasi documento Word
scegliendo la voce Strumenti -> Macro dal menu principale
e cliccando su Macro (o in alternativa premendo i tasti ALT
+ F8).
Apparirà
in tal modo la finestra denominata Macro che non rappresenta
altro che una lista delle funzioni generate dall'utente. Per
conoscere però le funzioni interne a Word bisogna fare
un passo successivo: dalla medesima finestra selezionare la
combobox 'Macro in' e scegliere la voce 'Comandi di Word', proprio
come mostrato in figura:
La
lista della finestra si popolerà con tutte le funzioni
interne a Word disponibili. Per conoscere il significato di
ciascuna funzione è sufficiente consultare la descrizione
posta nella parte bassa della finestra.
E'
necessario però specificare che tali funzioni sono
presenti sia nel modello predefinito che in un qualsiasi documento
generato dall'utente. Ma mentre le funzioni presenti su quest'ultimo
sono modificabili senza rischio per l'applicazione, una modifica
nel template predefinito si propagherà come visto poc'anzi
a tutti i documenti successivamente generati.
Le funzioni elencate rappresentano il punto di partenza di
un virus delle macro. Il ragionamento è il seguente:
non è possibile modificare direttamente il file Normal.dot
aggiungendo macro dannose. E' però possibile riprogrammare
le macro predefinite di un qualsiasi documento Word in modo
che causino danni all'applicazione e, per renderle presenti
ed attive in qualsiasi altro documento, salvarle nel modello
Normal.dot.
Naturalmente
se lo studio delle funzioni interne di Word fossero utili
solo per rendere inutilizzabile l'applicazione non ci sarebbe
motivo di analizzarle.
Questo lavoro risulta però molto utile nel caso in
cui si voglia comprendere a fondo la struttura dell'interazione
utente/applicazione Word per creare soluzioni efficienti.
Una delle tante è la generazione in un documento Word
di un report utilizzando Visual Basic.
|
