Newsgroup: it.comp.lang.visual-basic
Titolo: ActiveX DLL: Threading Model

Ciao a tutto il Newsgroup,
ho ereditato l'implementazione e la manutenzione di una applicazione che
associa alle funzionalità di un exe standard, i servizi di varie ActiveX
DLL.
Il complesso degli oggetti, aggregato in un VBG, simula una applicazione
MDI.
L'exe consta di uno splash e di un form *Main* (non MDI Parent), ogni
child perviene dalle DLL.
Fra queste, una fornisce l'accesso ai dati sul DB remoto (SQL Server), e
restituisce form pertinenti.
Una classe, 'clsInit', della DLL si occupa di connettersi al DB e
valorizza una ADODB.Connection con visibilità Public definita in un
.BAS, di modo che sia a disposizione delle altre classi e degli altri
moduli della DLL.
Fino a stamattina tutto bene: la sub Main dell'Exe istanziava
esplicitamente (Dim m_Initialize As New DLLXYZ.clsInitialize) la
clsInit, e gestiva correttamente tutte le classi di generazione dei form
Child generate tramite CreateObject("DLLXYZ.clsXXX").
Queste ultime classi sono Implements di una altra DLL (nel seguito
clsSuperClass).
Sono 3 mesi che integro e modifico il codice ma solo oggi ho compilato
il VBG.
Il compilatore ha sollevato legittime eccezioni di interruzione di
compatibilità con la definizione di riferimento, per altro i messaggi
erano già noti poichè li solleva anche con lo Start dall'IDE.
Ho cambiato le proprietà dei progetti imponendo "Nessuna Compatibilità",
ho deregistrato le precedenti DLL e finalizzato con MS RegClean.
Ho compilato tutto e registrato le nuove entry nel Registry.
L'Exe fallisce nell'eseguire i metodi di alcuni fra gli oggetti della
DLL.
Adesso in Debug, dall'IDE, noto che tutte le classi istanziate
esplicitamente (Dim ClassY As DLLXYZ.clsQwerty e relativa Set New)
condividono la connessione, ma tuttavia non interagiscono con le azioni
di debug, semplicemente si compiono senza che il contesto si sposti dal
codice form dell'Exe, mentre la classi create con Dim ObjX As
clsSuperClass - Set Objx = CreateObject("DLLXYZ.clsXXX"), sono estranee
alla connessione public, e sono collegate al flusso di debug.
Il modello di Thread della Dll è "Apartment Threaded", ogni singola
classe é MultiUse, NotAnMTSObject, NotPersistable.
Cosa è successo?
Quali azioni per rimediare?
Riuscirò a presentare l'anteprima della nuova release domattina ai
colleghi?
Un grazie in anticipo.
Adriano

 ha scritto nel messaggio
news:3AF1A3E8...@corner.ch...


Grazie Lorenzo per l'attenzione.
La compatibilità è stata volutamente interrotta: e il registry è stato pulito
anche per questo.
Nessuna altra applicazione utilizza le DLL registrate: solo i membri del VBG.
Io dopo aver ricompilato tutto, ho registrato le nuove DLL, tramite regsrv32, e
poi ho ricominciato a sviluppare nell'IDE aggiornando in ognuno dei progetti che
compongono il gruppo, le References, eliminando le MISSING e selezionando le
nuove.
Ma perchè l'Exe lancia due Threads separati?
Istanziare una DLL, con tutte le Late-Bound o le Early-Bound che necessitano a
run time, non dovrebbe creare un unico e solo Apartment per ogni Client, che
attualmente è l'unico, ovvero il mio PC?
Adesso non posso neppure più compilare la DLL. Rileva una 'sharing violation'.
Non vorrei giocare tutta la notte con regsrv32 e VB6 (sono ancora al
lavoro.........).
Allora la compatibilità è settata a "Nessuna" per ogni DLL.
Le DLL sono da compilare singolarmente o dal VBGroup?
E quindi se le devo compilare singolarmente, le registro quando create? devo
aggiornare le References negli altri VBP che le istanziano? E la reference deve
puntare alla registrata o a quella creata ex-novo?
E se le compilo dal VBG, non usando le default option per il path, per non
sovrascrivere quelle registrate, poi i riferimenti degli altri VBP sono
consistenti?
O le devo sovrascrivere con la compilazione?
Che casino. Non riesco a concentrarmi.
Un aiuto step by step per favore: sono disorientato e avvilito.


Un aiuto step by step per favore: sono disorientato e avvilito.
in bocca al lupo ;-)
ciao, hal

Grazie Hal1961 per le indicazioni e l'incorraggiamento.
Ho seguito le indicazioni tue e di Lorenzo per abbandonare il porto delle nebbie.
Ordinatamente ho deregistrato, compilato singolarmente, aggiornato i riferimenti a
cascata e la situazione *sembra* essersi ristabilita.
Un adagio popolare insegna che il sonno della ragione genera mostri. Anche il sonno del
programmatore.
Non sono proprio mostri dello stesso ordine ma si assomigliano.
È l'alba dopo una notte di fuoco, e risolta una, nessuna centomila antitesi della
ragione, subito si pone impunito un ulteriore dilemma, un nuovo quesito: ma questa,
gentili frequentatori, sarà dolce materia per una speculazione separata...
Grazie ancora.
Adriano
P.S. Ma Hal1961 è un tuo modo personale di conferire un encomio solenne a Stanley
Kubrick, (hal 9001 - 2001 Odissea nello spazio)?
Dai, (<- non in accezione britannica ovviamente), non sarà solo perchè sei Aldo nato nel
1961, vero? :-)
Ciao
hal1961 wrote:
[snip]


1961, vero? :-)
in realta' e' frutto di un mix:
volevo un nick univoco, ma un GUID mi sembrava esagerato --- 40%
hardware abstraction layer --- 20 %
come mi chiamano alcune persone care --- 15%
mi piace la colonna sonora del filmone di S.K. --- 10%
mi chiamo Aldo --- 10% 
sono del 1961 --- 5%
ciao, hal

 sono del 1961 --- 5%
...eppure anche un GUID... ;-)
Scherzi a parte, è uno dei nick più riusciti su questo NG.
Mi associo anche sulla qualità del film.
ciao
ugo