Questa è la quinta parte della serie dei post dedicati al mondo del COM. Come detto all'inizio questa tecnologia è molto "stagionata" e vintage, anche se tutt'oggi ancora ampiamente utilizzata, e la mia volontà di condividere con Voi i miei appunti su questo argomento è per aiutare quanti, come il sottoscritto, si trovano ancora a dover modificare ogni tanto dei progetti legacy.

Inoltre rappresenta anche un mio omaggio a una tecnologia che nel passato ha veramente rivoluzionato il mondo della programmazione.

Ecco i post precedenti.

Componenti COM: Introduzione - parte 1 di 6
Componenti COM: Le interfacce - parte 2 di 6
Componenti COM: Interface Definition Language .....anche chiamato IDL - parte 3 di 6
Componenti COM: vTable e dintorni - parte 4 di 6

Nel post precedente ho scritto circa i due metodi di accesso possibili a un COM Component.

Sorge allora spontanea una domanda. Perchè esistono due metodi per accedere agli oggetti COM ? Quali sono pregi e difetti di ogni metodo di accesso ?

Perchè dovrei usare la early binding rischiando, a seguito di una modifica improvvida della libreria (ricompilazione della stessa in NO Compatibilty), di perdere la possibilità di utilizzarla ?

Per iniziare occorre dire che alcuni linguaggi, che sono in grado di utilizzare componenti COM, semplicemente non supportano l'accesso tramite early binding !

Per esempio quello di scripting (uno tra tutti: il vecchio e glorioso vbscript).

Un altro motivo fondamentale è che un accesso a un componente COM in late binding è molto più lento rispetto a una accesso a un componente early binding.

Oss.: Ricordo che la tecnologia COM è stata progettata con computer che avevano capacità elaborative diverse da quelle attuali: anche se l'osservazione rimane valida tutt'oggi la velocità dei moderni elaboratori rendono spesso trascurabile questa differenza, perlomeno in ambiti di utilizzo normali.

Quindi in definitiva usando il late binding si ovviano ai problemi di compatibilità e interfaccia: lo scotto da pagare è una maggiore lentezza nel caricamenti dei metodi dell'oggetto creato.

Inoltre un altro problema è che il codice consumatore può essere soggetto a un numero maggiore di errori poichè in fase di editing e compilazione non verrà mai eseguito alcun controllo sul nome e argomenti dei metodi utilizzati.

Tale controllo viene eseguito solo quando si usa early binding.

Infatto l'effetto di creare un riferimento del progetto a un Com server sarà quello di caricare la relativa type library, che sarò utilizzata per verificare la correttezza dei metodi richiamati sia in fase di editing che in fase di compilazione.

Già che siamo qui occorre accennare qualcosa del COM Runtime. Questo parte del sistema operativo è delegata a fornire tutte le informazioni che riguardano i vari COM Server installati sulla macchina: un codice consumatore mai e poi accederà al registro di sistema per ricavare le varie info per poter accedere a una dll COM, bensì interogherà il COM Runtime, che eseguirà tutte le operazioni necessarie (restuizione informazioni, creazione instanze, etc)

….e QueryInterface ?? Solo per completezza riporto l'ultima interfaccia che viene aggiunta in modo silente a un COM component: QueryInterface. Dirò solo che serve per eseguire istruzioni come nel seguito: quindi per capire se una interfaccia, definita altrove tramite istruzione Interfaces, è supportata da un COM Component o meno.

Dim objInfPress As InfPressapochista
Dim objInfPressInterface As IInfPressapochista 'definita tramite interfaces


If TypeOf InfPressapochista Is objInfPressInterface Then
    Set objInfPress = new InfPressapochista
Else
    MsgBox "Interfaccianon supportata"
End If