[VB6] condivisione di una Collection
~Incoming
mi ero scritto una piccola utility che (idealmente) doveva gestire una
Collection da condividere con almeno 2 programmi.
Mi sono orientato su una dll activex, funziona tutto fatta eccezione per
quello che mi ero prefissato in origine. :-)
La dll espone una classe (settato in multiuse) come interfaccia di
codice per gestire la Collection, la Collection (che speravo di
condividere) e' dichiarato e inizializzato in un modulo standard.
Quando inizio ad usare il componente della dll con il programma A
la dll si inizializza e espone gli oggetti per gestire la collection,
fin qui perfetto, avviando l'applicazione B la dll, se pur inizializzata
da A, viene reinizializzata anche per B... perche' risulta ancora su
Nothing!
In pratica (forse causa dell'impostazione del progetto su una dll
activex? o della classe in multiuse?) pur caricando in memoria una sola
dll questa sdoppia tutto quello che ha al suo interno, anche la
Collection dichiarata in un modulo standard
In alternativa come posso fare per gestire una Collection unica da piu'
programmi?
Sperando di semplificare il concetto; desidererei usare la collection in
modo tale che se B lo modifica con A posso vedere la modifica
(chiaramente la dll l'avevo scritta con gli eventi necessari)
Ma l'errore di fondo sta nello sdoppiamento della collection. grrrr :-)
grazie a chi volesse aiutarmi.
Andrea [Work]
> Sperando di semplificare il concetto; desidererei usare la collection in
> modo tale che se B lo modifica con A posso vedere la modifica
> (chiaramente la dll l'avevo scritta con gli eventi necessari)
> Ma l'errore di fondo sta nello sdoppiamento della collection. grrrr :-)
Non conosco molto la roba che hai descritto, ma non mi pare possibile che
un eseguibile possa in qualche modo sapere di indirizzare della memoria
usata da un altro programma. Ogni programma istanzier� una diversa
collection.
Questi dati della collection non li puoi scrivere in una tabella in un
DB/File "condiviso"?
Tiscali
Se i due programmi girano sulla stessa macchina,
realizzi una stringa con dei delimitatori (per esempio chr(0)),
li copi nella ClipBoard,
e li ricarichi dall'altro programma.
--
Ciao Fede
By Chicco Production
http://bcp.freetools.it
Tiscali
oggetti!
~Incoming
<news:e8vs8y9ezdas.1wu8vjekyv6ts$.d...@40tude.net>
ci avevo pensato, ma non sono tanto avvezzo con dao e ado appunto per
aver sempre preferito l'istruzione open al metodo :-)))
infatti se non trovo suggerimenti aggirero' il problema con un registro
su file...pero' dovrei rilevare l'eventuale modifica al file per poi
aprirlo e non aprirlo ogni volta per controllare... miii l'hd si
suiciderebbe :-)
ora intanto smanetto un poco anche con un exe activex non si sa mai.
non sono i programmi a creare la collection, e' l'activex che lo
gestisce ...dovevaaa, per quanto riguarda la condivisione di porzioni di
memoria con vb, il passaggio per riferimento e' un passaggio
"dell'indirizzo" di memoria a meno che non si usi sempre byval.
~Incoming
<news:4b21588d$0$701$5fc...@news.tiscali.it>
mannaggia cosi' mi smonto...spero ancora di usare il comodissimo
raiseevent.
Andrea [Work]
> non sono i programmi a creare la collection, e' l'activex che lo
> gestisce ...dovevaaa, per quanto riguarda la condivisione di porzioni di
> memoria con vb, il passaggio per riferimento e' un passaggio
> "dell'indirizzo" di memoria a meno che non si usi sempre byval.
Come ti ho detto non ho mai creato activex, ma ogni programma istanzier� la
sua versione, non mi risulta da nessuna parte che si possa condividere la
stessa istanza di un oggetto.
La cosa pi� semplice mi sembra la condivisione dei dati in una tabella, con
eventualmente un sistema di avviso per quando un dato viene modificato, a
seconda del tipo di app.
Luca D
> Ciao,
> mi ero scritto una piccola utility che (idealmente) doveva gestire una
> Collection da condividere con almeno 2 programmi.
> Mi sono orientato su una dll activex
> In pratica (forse causa dell'impostazione del progetto su una dll
> activex? o della classe in multiuse?) pur caricando in memoria una sola
> dll questa sdoppia tutto quello che ha al suo interno, anche la
> Collection dichiarata in un modulo standard
il punto della questione sta tutto in: *DLL*
Poichè la DLL per definizione vive nello stesso processo
dell'applicazione chiamante, è vero che *Il codice* viene caricato in
memoria una volta sola, ma *le variabili* sono allocate in maniera
isolata (perchè non possono invadere lo spazio dell'altro processo).
Questo vale non solo per le classi MultiUse, come già ti aspettavi, ma
anche per tutte le variabili globali messe in un modulo.
Per ottenere quello che vuoi tu, ti serve un componente COM "out-of-
process" ovvero definire un progetto di tipo EXE ActiveX
Gli EXE ActiveX espongono librerie di classi in maniera del tutto
analoga alla DLL ma, quando si attivano, vengono caricati in un
proprio processo a parte, separato dal processo chiamante (lo vedi
espressamente nel TaskManager); Se usi solo classi MultiUse, la prima
istanza che viene invocata, carica anche l'exe in memoria, le altre
vengono attivate nel processo caricato in precedenza.
A differenza della DLL cosa cambia?:
le classi MultiUse sono isolate e istanziate autonomamente, ma le
variabili globali dichiarate in un modulo sono invece *CONDIVISE* da
tutte le istanze.
Rafunk
[cut]
> Per ottenere quello che vuoi tu, ti serve un componente COM "out-of-
> process" ovvero definire un progetto di tipo EXE ActiveX
>
> Gli EXE ActiveX espongono librerie di classi in maniera del tutto
> analoga alla DLL ma, quando si attivano, vengono caricati in un
> proprio processo a parte, separato dal processo chiamante (lo vedi
> espressamente nel TaskManager); Se usi solo classi MultiUse, la prima
> istanza che viene invocata, carica anche l'exe in memoria, le altre
> vengono attivate nel processo caricato in precedenza.
>
> A differenza della DLL cosa cambia?:
> le classi MultiUse sono isolate e istanziate autonomamente, ma le
> variabili globali dichiarate in un modulo sono invece *CONDIVISE* da
> tutte le istanze.
Aggiungo: a patto che il threading model sia "thread pool" con dimensione 1 thread (che tra l'altro mi pare sia il default).
Altrimenti ogni thread avr� una *copia* privata delle variabili "globali" (nel thread local storage), vanificando cos� la
possibilit� di condivisione.
Ciao
Raf
~Incoming
<news:5ede7f7e-a949-46e3...@n35g2000yqm.googlegroups.com>
> On 10 Dic, 12:53, ~Incoming <speriamo.che.m...@cavo.it> wrote:
> ...
>
> Gli EXE ActiveX espongono librerie di classi in maniera del tutto
> analoga alla DLL ma, quando si attivano, vengono caricati in un
> proprio processo a parte, separato dal processo chiamante (lo vedi
> espressamente nel TaskManager); Se usi solo classi MultiUse, la prima
> istanza che viene invocata, carica anche l'exe in memoria, le altre
> vengono attivate nel processo caricato in precedenza.
>
> A differenza della DLL cosa cambia?:
> le classi MultiUse sono isolate e istanziate autonomamente, ma le
> variabili globali dichiarate in un modulo sono invece *CONDIVISE* da
> tutte le istanze.
bravo Luca!
e funziona come desideravo ...o quasi, nel passare il progetto da
dll activex a exe deve essersi ingarbugliato il registro di windows
:-DDD
per debugare (passatemi il termine) apro due istanze di vb sulla prima
avvio l'exe dopo averne compilato e salvato una copia su disco
sulla seconda istanza carico un progetto per testare l'exe, come avvio
questo progetto di prova mi restituisce subito errore 430!
ho compilato l'eseguibile A, lo clonato in B (per avere due programmi
che s'interfacciano con l'exe active x) e provato:
l'errore all'avvio non c'e', con A se chiedo al gestore della collection
di cancellare un elemento la notifica arriva anche a B proprio quello
che mi aspettavo :-D
cosi come altre proprieta' del gestore funzionano, e' comparso l'errore
430 quando ho chiesto di aprire il form interno, ma dopo qualche
riavvio, molto stranamente, gli eseguibili si sono iniziati ad
interfacciare con l'exe activeX senza problemi anche per aprire il
form!!!
rimane il problema dentro l'ide bohh! :-}
quell'errore 430, ho eseguito un paio di utility per pulire il registro,
ma non va!
tra i riferimenti disponibili dentro vb effettivamente ci sono due voci
relativi alla prima dll activex, la seconda a uno dei primi exe
creati...e non c'e' verso di toglierli.
grazie delle risposte a tutti