OCX si o OCX no?

Mauro VB Homepage - Articoli di Claudio Gucchierato

Per un neo programmatore (ma spesso anche per chi 'neo' non lo è più) l'utilizzo degli OCX (OLE Custom Control o ActiveX®) rappresenta spesso una tentazione, se non un vera e propria necessità, irrinunciabile. I componenti esterni, infatti, consentono con la stessa semplicità di utilizzo dei componenti thunder¹ (i controlli standard presenti in Visual Basic che vengono automaticamente inseriti all'interno del nostro programma compilato) di ottenere risultati professionali e di risolvere i problemi relativi alla progettazione e realizzazione di oggetti personalizzati. Tra l'altro molti OCX sono gratuiti e facilmente disponibili, quindi, la spinta al loro utilizzo risulta ancora di più incentivata ma... non è tutto oro quello che luccica, e vediamone brevemente il perché.

Gli OCX, in quanto componenti ActveX®, devono obbligatoriamente essere registrati nel sistema. La registrazione deve essere fatta automaticamente (difficilmente si può chiedere all'utilizzatore del nostro programma di registrare manualmente i nostri controlli...) e ciò comporta la necessità di distribuire le nostre applicazioni con una adeguata procedura di installazione (e disinstallazione) in grado di eseguire questa operazione in modo automatico e trasparente.

Gli OCX, solitamente, hanno dei file di dipendenza (come per Visual Basic che dipende dai file di RunTime), di conseguenza alle volte occorre distribuire anche quest'ultimi (sempre se siamo in grado di sapere quali essi siano) assieme alla nostra applicazione per avere la certezza che tutto funzioni senza problemi.

Gli OCX possono essere coperti da copyright, conseguentemente il loro utilizzo può essere vincolato o limitato.

E, per finire, gli OCX, per loro natura e struttura, possono anche veicolare del malware (programmi "nocivi" per il PC quali virus, backdoor, trojan horse e similari) in grado di infettare i computer nei quali viene installato il nostro "innocente e pulitissimo" programma. (Ovviamente questo tipo di rischio è limitato all'utilizzo di OCX "anonimi" scaricati liberamente dalla rete).

Detto questo, com'è vero che non è tutto oro quello che luccica, è altrettanto vero che il diavolo non è poi così cattivo come di solito si dipinge.

Più sopra ho cercato, un po' criticamente, di evidenziare i soli aspetti negativi riguardanti l'utilizzo dei componenti esterni, ma certamente in molti casi l'impiego degli OCX è praticamente necessario, se non indispensabile. Pensiamo, ad esempio, ai Microsoft Windows Common Control (COMCTL32.OCX) dove sono disponibili controlli del tipo TreeView o ListView, immaginare di costruirci "in casa" controlli di questo tipo, anche avendo le conoscenze e le capacità necessarie, è assurdo e improponibile, quindi, utilizzare i controlli esterni diventa giustificato e, anzi, raccomandabile, visto che, oltretutto, essendo adeguatamente collaudati sono anche ragionevolmente privi di bug. Ma, se da un lato è giustificato utilizzare un OCX per disporre di componenti complessi e sofisticati tipo Treview o ListView, dall'altro non lo è di certo quando si utilizzano componenti relativamente semplici tipo ProgressBar o StatusBar. Con un minimo di impegno, infatti, questi ultimi possono essere facilmente emulati, sia nelle funzionalità e sia nella grafica, con poche righe di codice. A mio avviso, infatti, il programmatore dovrebbe essere non solo tecnico, ma anche un po' "artigiano". Con un pizzico di fantasia, e aiutandoci con i mezzi che VB mette a disposizione, possiamo utilizzare un banalissimo controllo "Label" o "Shape", per creare una progressbar con estrema facilità, e se aggiungiamo un controllo PicureBox, e qualche altra label, possiamo anche realizzare una StatusBar... diamo sfogo, quindi, all'"artigiano informatico" che è dentro in ognuno di noi!

Concludo questa breve chiacchierata, il cui solo e unico scopo è quello di far riflettere sui pro e sui contro relativi all'utilizzo di componenti esterni nelle nostre applicazioni, ricordando che in rete si possono trovare e scaricare liberamente Classi o UserControl che, non essendo compilati, possono essere inseriti direttamente all'interno della nostra applicazione ottenendo gli stessi risultati dei controlli esterni, ma senza i problemi e i rischi che l'utilizzo di questi ultimi può comportare. A questo proposito ricordo che nella sezione Risorse-Programmatori è disponibile la classe (ampiamente commentata) Open and Save che serve per la gestione delle finestre "Apri" e "Salva" senza l'uso del controllo Common Dialog (COMDLG32.OCX) di Visual Basic; inoltre, sempre nella medesima sezione, potete trovare l'esempio Barre di Avanzamento Colorate che mostra come creare delle semplici ProgressBar personalizzabili senza utilizzare nessun controllo esterno.

In definitiva, utilizzate controlli esterni solo in caso di controlli complessi, in tutti gli altri casi cercate di creare voi stessi i controlli che vi servono o, in alternativa, cercate in rete una classe o un modulo in grado di esplicare le stesse funzioni dell'OCX che intendete usare.

Buon lavoro!

(¹) Thunder è il nome "interno" dei controlli standard presenti in Visual Basic. I controlli Thunder sono: Label, CommandButton, TexBox, PictureBox, Frame, H e V ScrollBar, Drive, Dir e File ListBox, Timer, Shape, Line, Data, Ole e Form.