Newsgroup: it.comp.programmare.win32
Titolo: [COM e C++] cambio on the fly della interface

Ciao a tutti, avrei un piccolo quesito da sottoporvi.
Ho creato un oggetto COM con supporto a IDispatch (e TypeLib annesso),
questo oggetto e i suoi metodi/proprietà sono visibili da vbs e vba (word).
Il mio problema è questo (e spero di essere chiaro):
 A = Oggetto
 B = Proprietà di A (A.B)
B può essere un'interfaccia di tipo Ix o Iy (definite nel mio codice), solo
che la scelta varia dinamicamente a seconda di altre funzioni eseguite
sull'oggetto stesso.
Es.:
    A.versione = 1  B è di tipo Ix
    A.versione = 2  B è di tipo Iy
E possibile gestire una cosa del genere ?
Grazie
Giuliano

 ha scritto nel messaggio
news:rtTrb.105566$vO5.4...@twister1.libero.it...

Uhmmm...
Mi sembra una potenziale violazione di QueryInterface che, quando
invocata sullo stesso oggetto, *deve* fornire le stesse interfacce
a seguito di chiamate successive.
Invece nel tuo caso si avrebbero comportamente diversi...
Suggerimento: il meccanismo delle interfacce e' stato introdotto
per risolvere problemi tipo il tuo. Semplicemente il tuo oggetto
rispondera' di avere Ix se richiesto (suppongo un'interfaccia piu'
vecchia e meno evoluta), ma rispondera' di avere anche Iy (che
suppongo piu' recente ed evoluta) a chi ne conosce l'esistenza.
Ciao. Federico Molara.

 ha scritto nel messaggio
| news:rtTrb.105566$vO5.4...@twister1.libero.it...
|
| Suggerimento: il meccanismo delle interfacce e' stato introdotto
| per risolvere problemi tipo il tuo. Semplicemente il tuo oggetto
| rispondera' di avere Ix se richiesto (suppongo un'interfaccia piu'
| vecchia e meno evoluta), ma rispondera' di avere anche Iy (che
| suppongo piu' recente ed evoluta) a chi ne conosce l'esistenza.
Effettivamente non č Ix o Iy a essere di differente versione, ma l'oggetto
stesso che data la versione differente dovrebbe rispondere con
un'interfaccia diversa (e con diversa intendo proprio questo, non una
versione piů evoluta).
Purtroppo la versione dell'oggetto non la conosco a priori (visto che
l'oggetto in questione č qualcosa di fisico con cui comunico via seriale) e
l'utente che crea l'oggetto (CreateObject) potrebbe non saperla (un metodo
dell'interfaccia ritorna informazioni utili per la determinazione dei metodi
supportati dall'interfaccia stessa).
Sicuramente la logica di implementazione degli oggetti COM prevede di creare
una classe per ogni versione, ma come fa l'utente/programmatore a scegliere
quale versione dell'oggetto creare se non sa quale versione di dispositivo
sta utilizzando ?
Ciao e grazie per l'aiuto
Giuliano

 supportati dall'interfaccia stessa).
Allora mi sembra semplice: crea un oggetto COM in grado di interrogare
l'hardware
e capire quale oggetto (sempre COM) serve per quell'hardware. Mi sembra di
capire
che questa parte di programma ce l'hai gia', quindi basta isolarla in un
oggetto
a parte.
Soluzione 1:
Il tuo utente (che immagino un programmatore o un un programma) dovra'
utilizzare
questo oggetto per ottenere un valore (grazie a una proprieta') che gli
servira'
per determinare i giusti parametri (tipo di oggetto) da passare alla
CreateObject()
Soluzione 2:
L'oggetto in questione (quello che capisce il tipo di hw), ha un metodo in
grado
di crearti lui il tipo giusto di oggetto (scusa la ripetizione, ma hai
capito) in
base alle deduzioni che ha fatto.
Ciao.
Federico molara.

 ha scritto nel messaggio
| news:4Kcsb.108140$vO5.4...@twister1.libero.it...
|
| Bhe, detto cosi' mi fai pensare che fai confusione fra oggetto COM e un
| oggetto inteso come dispositivo hardware, ma sono sicuro che non e' cosi'!
| :)
|
Effettivamente ho incasinato un po' il concetto, ma vedo che hai capito bene
cosa intendevo.
| Soluzione 1:
| Il tuo utente (che immagino un programmatore o un un programma) dovra'
| utilizzare
| questo oggetto per ottenere un valore (grazie a una proprieta') che gli
| servira'
| per determinare i giusti parametri (tipo di oggetto) da passare alla
| CreateObject()
Questa soluzione è praticabile, però, una domanda:
Considera che lo sviluppatore utilizza vba (comodo perchè mentre digiti ti
da indicazioni sui metodi/proprità), se per esempio l'oggetto che fa il
detect della versione del dispositivo mi ritorna, che so, "OggVer1" e lo
passo a CreateObject, devo dichiarare la variabile di appoggio tipo object
(o simile) perdendo l'aiuto di cui sopra.
| Soluzione 2:
| L'oggetto in questione (quello che capisce il tipo di hw), ha un metodo in
| grado
| di crearti lui il tipo giusto di oggetto (scusa la ripetizione, ma hai
| capito) in
| base alle deduzioni che ha fatto.
|
Questa soluzione mi permette di creare direttamente l'oggetto in base al
dispositivo identificato (ovvere il metodo dell'oggetto COM mi ritorna
l'oggetto che serve per gestire il dispositivo... e vai con le ripetizioni
;-) ); ma come per sopra vba non mi aiuterebbe più durante la fase di
digitazione.
Io avrei pensato anche ad una terza ipotesi, e cioè quella di fare un merge
delle due interfacce (cosi avrei dei metodi/proprietà non utilizzate per
alcune vers. del dispositivo) e il programmatore determina quelle da
utilizzare in base alla "solita" proprietà/metodo di detect. Tu cosa ne
pensi di questa soluzione ? In questo modo vba mi darebbe sempre l'aiuto
durante la digitazione.
Qui sotto trovi le due interfacce in questione, cosi ti farai un'idea su
cosa devo fare il merge.
interface IBitParameter : IDispatch
    {
    [propget, id(1)] HRESULT ParamType ([out, retval] int *lpParamType);
    [propget, id(2)] HRESULT ParamSize ([out, retval] int *lpParamSize);
    [propget, id(3)] HRESULT ParamNum ([out, retval] int *lpParamNum);
    [propget, id(4)] HRESULT ParamBit ([out, retval] int *lpParamBit);
    [propget, id(5)] HRESULT ParamValue ([out, retval] VARIANT_BOOL
*lpParamValue);
    [propput, id(5)] HRESULT ParamValue ([in] VARIANT_BOOL newParamValue);
    }
interface IParameter : IDispatch
    {
    [propget, id(1)] HRESULT ParamType ([out, retval] int *lpParamType);
    [propget, id(2)] HRESULT ParamSize ([out, retval] int *lpParamSize);
    [propget, id(3)] HRESULT ParamNum ([out, retval] int *lpParamNum);
    [propget, id(4)] HRESULT ParamMinValue ([out, retval] long *lpParamMin);
    [propget, id(5)] HRESULT ParamMaxValue ([out, retval] long *lpParamMax);
    [propget, id(6)] HRESULT ParamValue ([out, retval] long *lpParamValue);
    [propput, id(6)] HRESULT ParamValue ([in] long newParamValue);
    }
Ciao
Giuliano

 durante la digitazione.
Scusa ma ora non ti seguo piu'!
Mi parli di dare la possibilita' di scegliere dinamicamente fra
tipi di oggetto legati a tipi di hw diversi, e questi sono aspetti
legati tipicamente alla fase di run-time, almeno questo avevo capito.
Poi mi parli di completmento automatico, funzionalita' che tipicamente
e' offerta da VB in fase di design-time, o comunque di scrittura del
programma. Le due cose stridono alquanto!
Persegui la terza strada, non e' stilisticamente elegante, ma si adatta
allo scopo che vuoi raggiungere.
Ciao. Federico.

 ha scritto nel messaggio
| news:Prwsb.110499$vO5.4...@twister1.libero.it...
| >
|
| Mi parli di dare la possibilita' di scegliere dinamicamente fra
| tipi di oggetto legati a tipi di hw diversi, e questi sono aspetti
| legati tipicamente alla fase di run-time, almeno questo avevo capito.
|
| Poi mi parli di completmento automatico, funzionalita' che tipicamente
| e' offerta da VB in fase di design-time, o comunque di scrittura del
| programma. Le due cose stridono alquanto!
|
In realtà volevo ottenere entrambe le cose, gestire in dinamica la versione
hw e dare la possibilita in qualche modo di facilitare le cose a chi
utilizza vba.
Sono concorde con te, la mia soluzione non è stilisticamente bella e
considerando che non c'è modo di ottenere "tutto" quello che voglio e che
quindi dovrò per forza scegliere una delle due strade, preferisco lasciar
perdere vba e seguire una delle soluzione che mi hai proposto.
Grazie per tutto il tuo supporto
Giuliano