Newsgroup: it.comp.lang.c++
Titolo: Problema di integrazione fra Visual C++ e VB5


Salve a tutti.

    E' da poco che lavoro con Visal C++ e sto cercando
di integrare un OCX (ImageEdit di WANG) con Visual Basic E Visula C++.
Vi sarei molto grato se mi deste un aiuto.


 In particolare ho questa necessita':

  Da un form di un programma VB5 in cui ho inserito il controllo
ImageEdit devo chiamare un funzione presente in una DLL da me scritta,
in cui effettuo una opearazione sul controllo . In altre parole devo richiamre
una funzione C, passando il controllo ImageEdit e un nome di un file e
all'interno di questa funzione eseguire una SHOWIMAGE che e' un metodo
del controllo.

 In sintesi e' possibile dichiarare un controllo in VB5 e poi
fare delle operazioni sul controllo (usare i suoi metodi e proprieta')
in C++ ? Se si in che modo posso passare il controllo ImageEdit alla funzione
C ?


  Quello che segue e' un esempio:


**** File form1.bas ****


sub command1_click()

  mia_funzione (
Imagedit1
,"pippo.tif")

end sub


**** File mia_funzione.cpp ****


mia_funzione (
ClassImagedit 
*mio,char *filename )

  mio.ShowImage(filename);

end sub


Vorrei sapere la corretta dichiarazione in VB5 di "mia_funzione" e il
prototype in Visual C++

 

 


si in che modo posso passare il controllo ImageEdit alla funzione C ?
Non conosco specificamente il controllo in questione, ma di certo puoi
esplorarlo (ad esempio con l'OLE/COM Control Viewer) esaminando la
sua type library e vedendo in particolare come si chiama e come e`
fatta la sua interfaccia (sperabilmente custom o dual, ma anche con una
dispinterface ci si salva, sia pure a fatica:-) che vuoi passare al C++.
Supponiamo ad esempio che si chiami IEditImage, con tutti i suoi
attributi, metodi, e proprieta`.
La cosa piu` semplice, naturalmente, e` tenere tutto su di una omogenea
base di COM, usando anche per il tuo C++ un servente COM in process
piuttosto che non un altro tipo di DLL.  Con VC++5, l'ATL 2.1, e i relativi
wizard, non e` difficile; ho descritto in un post recente la semplice
sequenza
necessaria per generare la DLL di un in-process server COM.
Supponiamo che tu abbia chiamato IPippo la tua interfaccia custom,
realizzata presumibilmente da una coclass Pippo, implementata a sua
volta da una classe C++ CPippo che l'ATL Wizard ha generato per te,
ma ancora senza metodi.  Adesso, copia-e-incolla dalla typelib del
control di tuo interesse la definizione IDL di IEditImage nell'IDL del
tuo nuovo progetto, e aggiunti ad IPippo un metodo XY, parametri
    [in] IEditImage* p, [in] BSTR FileName
ed eventuali altri che possano servirti.  Il wizard inserira` tutte le
dichiarazioni necessarie e in particolare un metodo vuoto del tipo:
HRESULT
CPippo::XY(IEditImage *p, BSTR FileName)
{
    // TODO: ecc ecc
   return S_OK;
}
Al posto del //TODO, metti ora il codice che vuoi, tipo una chiamata
    p->ShowImage(FileName)
o che altro.  Compila il tutto, il wizard provvedera` anche a registrare
il tuo in-process COM server, la sua libreria, ecc ecc.  Dal Visual
Basic, Project/References ti permettera` ora di attivare la typelib
di Pippo e usarne i contenuti.  Quindi farai qualcosa del tipo:
    dim pluto as new Pippo
e, dove ti serve, chiamerai
    pluto.XY imed, "filename"
presumibilmente con un
    dim imed as IEditImage
opportunamente settato all'interfaccia in questione del tuo control.
Vedrai che il VB ti mostra, tra l'altro, che pluto.XY ha parametri:
    p as IEditImage, Filename as string
che e` anche quel che devi dire (o almeno una delle possibilita`!)
se vuoi realizzare il C++ senza il beneficio della tecnologia COM,
cioe` con una DLL nuda e cruda (ma allora quella DLL dovra`
presumibilmente "taroccarsi" da sola l'accesso al COM, invece
di sfruttare la comodita` dell'ATL e dei suoi Wizard... se sei certo
che tutto e` sempre nello stesso thread dello stesso processo,
si puo` anche fare, ma in qualsiasi altra circostanza puo` entrare
in gioco il marshaling, e allora, addio... personalmente, io ti
consiglio _decisamente_ di abbracciare al 100% il COM, invece
di vivere in un mondo "ibrido" dove tante delle cose che attacchi
al VB, per esempio tutti gli OCX, parlano in COM, e altre, tipo le
tue DLL custom, parlano invece altri "dialetti" taroccati...:-).
Ah, per le dispinterface, se e` con quello che ti trovi a combattere,
l'ATL puo` ancora aiutare, qui ad esempio con il generatore di
proxy (ha qualche micro-baco, ma puo` comunque tornare utile,
sapendo cosa rappezzare).  Se ti serve, chiedi!
Facci un po' sapere se queste indicazioni ti sono servite a
qualcosa...!
Alex