Il blog di Francesco Cadin

VBA è il "parente povero" di Visual Basic 6, perchè ha qualche marcia in meno. Ma qualche risultato decente, in termini di produttività spicciola, lo si può raggiungere lo stesso...

Un giorno mi posi il problema di capire le "Collection class". Queste sono classi particolari che avvolgono un oggetto Collection, mantenendone i riferimenti all'interno della classe che li avvolge, e ne espongono proprietà e metodi con un'interfaccia simile, in modo che il codice creda di avere a che fare davvero con una Collection.

Implementai quindi una Collection Class in un mio piccolo modello Word (gestiva un indirizzario di nominativi, memorizzati in un database con un formato proprietario) e incontrai subito alcune esigenze particolari.

1) definire una qualsiasi proprietà come membro di default di una Classe

In VBA, dove a differenza del VB non esiste la finestra degli attributi di procedura, bisogna esportare la classe, modificare il file .cls in modo da aggiungere la linea che segue alla proprietà che si desidera rendere default della Classe:

"Attribute Item.VB_UserMemId = 0"

In questo caso, la proprietà Item diventa il membro di default; e il gioco è fatto. Ma bisogna poi ricordarsi di NON salvare il modulo di Classe nell'IDE del VBA, altrimenti si perdono questi Attributi nascosti... chissà perché =o)

2) aggiungere il supporto per l'enumerazione degli elementi utilizzando il ciclo "for each"

Come in VB6 si deve creare nel modulo di Classe una funzione piuttosto sibillina:

Function NewEnum() As IUnknown

   Set NewEnum = m_myClass.[_NewEnum]

End Function

In VBA, non essendo disponibile la finestra di dialogo degli attributi di procedura , bisogna agire come al precedente punto 1 e aggiungere a mano le due linee di 'attributo nascosto' che seguono:

Attribute NewEnum.VB_UserMemId = -4      ‘ID routine

Attribute NewEnum.VB_MemberFlags = "40" 

Quindi:

(a) create la classe, (b) salvate, (c) esportate la classe, (d) rimuovete la classe, (e) aggiungete manualmente gli attributi come visto, (f) reimportate la classe così editata (e non salvarla più nell'IDE).

3) salvare di colpo su disco l'intera collezione di elementi (anche detto problema della serializzazione o persistenza dei dati)

In VBA non si può e in VB6 bisogna ricorrere ad artifici (invece .Net prevede la clausola Serializable, se non sbaglio). Purtroppo la property bag (disponibile in VB6) non esiste per VBA (ho trovato bensì degli ActiveX di terzi che ne simulano l’utilizzo, ma volevo una soluzione il più possibile indipendente). Bisogna optare per strade alternative quali recordset disconnessi, xml, file .ini o di testo, file ad accesso casuale (ringrazio ancora Mauro Technical per i suoi suggerimenti di allora). Io non ho ancora risolto questo punto :o)

Il D. Lgs. 626/94, che intende tutelare la sicurezza del lavoratore in azienda, sta per subire un pesante rifacimento (e riammodernamento). Dalla sua nascita ad oggi, infatti, si sono susseguite molte correzioni, modifiche e integrazioni che hanno fatto diventare questa normativa un tantinello confusa. Quando nascerà il nuovo Testo Unico, probabilmente, non si chiamerà nemmeno più "626", con buona pace della Beghelli :o)

Dal punto di vista che ci riguarda, notiamo che il D. Lgs. 626 (affettuosamente da sempre chiamato "la 626", senza l'anno di riferimento e al femminile, elevando così questo decreto al rango di Legge, anzi "la" legge) si occupa di diverse tipologie di rischi per la salute del lavoratore, dedicandovi appositi "Titoli".

Uno di questi Titoli riguarda la salute del lavoratore al videoterminale (VDT), per cui è tale chi lavora al VDT per almeno venti ore settimanali, dedotte le pause. Essere videoterminalista è importante (per la legge e per l'Azienda), perchè esistono obblighi e oneri a carico sia del datore di lavoro che del lavoratore. Ma la normativa non dice niente di specifico nè su qual è il rischio effettivo da VDT, nè in che modo si qualifica un videoterminalista, nè sulle misure da adottare per eliminare il rischio.

Essere videoterminalisti non è una brutta cosa, non succede nulla (affaticamento e astenia temporanea degli occhi a parte), tranne un controllo medico ogni due-tre anni a carico dell'Azienda, che si preoccupa della salute degli occhi dei dipendenti :o)

Il mio ufficio si occupa di 626 a livello aziendale, interno. Quindi abbiamo dovuto applicare la normativa ai dipendenti aziendali, circa ottomila sparsi sul territorio provinciale, verificando per ciascuno il tempo passato al VDT, le modalità di utilizzo del computer, e suggerendo al datore di lavoro le misure idonee a limitare/ridurre il rischio da VDT.

Il primo passo è stato installare sui p.c. di un campione di dipendenti, consenzienti e coscienti, un software che monitorizza i tempi di utilizzo. Viene intercettato e calcolato il tempo di non-utilizzo del mouse e della tastiera per dedurne le pause.

Abbiamo quindi realizzato un questionario, molto articolato e dettagliato, compilato dai Tecnici del mio ufficio durante un sopralluogo per ogni postazione di lavoro al VDT segnalata da ciascun datore di lavoro (l'Azienda conta 17 datori di lavoro e un Direttore generale). I dati risultanti dalla compilazione del questionario sono stati poi inseriti in un programmino Access che ha fornito un grazioso e corposo corposo elaborato finale (pubblicato dal mio ufficio qualche settimana fa).

Il programmino Access, piuttosto semplice come filosofia ma abbastanza arcigno in alcuni punti, l'ho fatto io da zero, risolvendo i problemi via via grazie a molti aiuti ricevuti dai partecipanti alla Mailing List e al Forum VB6 di VB-T&T. I dati constano di un'anagrafica (generalità, dati personali, ubicazione dell'ufficio), di una descrizione del luogo (posto di lavoro: arredi, dotazione, ergonomia, illuminazione), di un'analisi del software utilizzato (tipologia, frequenza di utilizzo, impressioni soggettive sulla facilità d'uso). L'elaborazione dei dati, per arrivare a stabilire se un dipendente è o non è videoterminalista, è stata lasciata ad una bellissima procedura che calcola, mediante diverse interpolazioni dei dati forniti, una media ponderata dei tempi di esposizione e di non esposizione (con correzioni sulle stime per eliminare i picchi anche dovuti alle autodichiarazioni).

Il DB lavora in locale. Ho provato a costruire un sistema che prelevi i dati in intranet, ma le tabelle collegate mi hanno dato insuperati problemi di lentezza della connessione.

Questo programmino Access ha funzionato egregiamente per i mesi di inserimento dati e per l'elaborato finale. Dovrà tuttavia essere rielaborato in occasione degli aggiornamenti (si prevede un prossimo aggiornamento dei dati tra tre anni circa). E' mia intenzione prevedere modifiche quali una rivistazione della grafica, uno storico delle entries e un supporto ai moduli con OCR (in modo da non dover ribattere i dati, evitando così errori di inserimento).

Non vorrei dilungarmi troppo in questo post. Resto a disposizione di chi fosse interessato, sia per i particolari normativi della 626, che per gli approfondimenti tecnici del programmino Access da me creato.