Newsgroup: it.comp.lang.c++
Titolo: Conversioni VB ->VC++ e puntatori

Io e un mio amico stiamo programmando un software, solo che lui usa VB5 e io
VC++5. Io devo sviluppare una DLL che deve fare il seguente:
[VB5]
Dim ok as Boolean
ok = TrovaLink(byval Code as String, byref URLs as String, byval Img as
Boolean)
come devo definire la funzione nella Dll?
BOOL TrovaLink(CString Code, CString* URLs, BOOL Img)
{
    ora devo cambiare il valore di URLs. Dunque se faccio
    *URLs += "pippo";
}
    Esegue quello che gli ho ordinato, ma quando l'esecuzione torna al
programma principale mi dice che c'è un problema: qualcosa come "il
puntatore appartiene ad un altro heap". Che devo fare? E che vuol dire?
Tra l'altro, è giusta la conversione as String -->  CString o devo usare
char xxx[] ?
Riccardo
scozz...@iol.it

char xxx[] ?
No, e qui sta il tuo problema: una String del VBasic corrisponde, in C o
C++, a una BSTR -- deve essere allocata solo con SysAllocString, ecc
ecc.  Devi, tra l'altro, includere oleauto.h, chiaro segno che C/C++ e
Basic "dovrebbero" comunicare solo attraverso OLE Automation (e
altre versioni/varianti del Component Object Model), anche se poi,
naturalmente, e di solito con maggior fatica, si riesce anche a
taroccare
una serie di palle curve ad hoc, approccio apparentemente molto, molto
popolare ("come faccio a dichiarare/implementare una DLL in C++ per
chiamarla da Visual Basic" e` sicuramente una delle domande che si
vede ripetersi piu` spesso in questo gruppo).
Personalmente, penso che si faccia prima ad imparare e applicare
l'ATL per mettere insieme un servente COM in-process, che non a
risolvere tutti i problemi causati dall'interfacciamento ad hoc (tipo
l'uso
di BSTR, e di tutta la dannata schiera di SysAllocString e compari).
Dopodiche`, con Project/References del Visual Basic, si aggancia
la type-library e si vive per sempre felici e contenti.
Comunque, ho gia` postato spesso in merito, e visto anche il feedback
avuto quando di recente ho dato la URL di un mio piccolo paper
introduttivo
a COM e tecnologie correlate (zero assoluto), pare proprio che la
preferenza generale sia per l'ad-hoc-chite acuta, quindi, have fun!-)
A;ex


Ho dato un'occhiata su come creare una DLL con ATL + MFC, ma ho incontrato
un po' di problemi dato che non l'avevo mai fatto prima - e io non sono
neanche tanto esperto.
Però mi farebbe piacere se tu mi potessi indicare qualche sito / libro che
tu conosci in modo che io possa approfondire la questione.
Ciao.
Riccardo

tu conosci in modo che io possa approfondire la questione.
Se c'e` un sito che possa aiutare, sara` probabilmente 
www.codeguru.com
;
ha buon materiale medio-avanzato su MFC e su ATL, non so pero` se ne
ha su come fondere i due framework entro la stessa struttura.
Li ed Economopoulos, in "Professional Visual C++ 5 ActiveX COM Control
Programming", se la cavano nel modo piu` semplice: in ogni dato progetto
usano *o* MFC (ad esempio quando hanno da fare GUI complesse), *o*
ATL (per progetti "back-end", con GUI semplici o assenti).  Evitano
cosi` la
piu` grande difficolta`, che e` appunto la fusione dei due ambienti;
pero`
non arrivano a sviluppare "dual-interfaces" per progetti MFC (accennano
appena alla Technical Note Microsoft che spiega come fare -- e` una
faticaccia non da poco).
Meglio, secondo me, Grimes, Stockton, Reilly e Templeman, "Beginning
ATL COM Programming" (questo testo, come il precedente, sono della
Wrox Press).  E` un testo piu` introduttivo, ma, sin dove arriva, le
cose
le porta piu` a fondo (differenza fondamentale: gli esempi di GSR&T sono
"esempi giocattolo", mentre L&E sviluppano un "vero" esempio
applicativo,
il che gli consuma il grosso delle pagine...).  Comunque, e giustamente
in
questo caso trattandosi di testo introduttivo, anche loro non dicono
molto
su di un argomento cosi` complesso e avanzato come la fusione dei due
framework nello stesso progetto, limitandosi a rimandare all'apposito
articolo della Knowledge Base (Q173974, se puo` servirti).
L'unico testo che ho, che affronti di petto la questione, e` Armstrong,
"Active Template Library, a developer's guide" -- non e` un grande
testo,
ma, su questo specifico argomento, meglio di niente (M&T/IDG Books).
Passa un 3 pagine circa a spiegare perche` e` meglio non farlo 99%
delle volte, e come si puo` evitarlo, ma poi tira un bel respirone e in
circa altre 12 pagine spiega, e mostra con un esempio, come si puo`
raggiungere lo scopo, nei due modi: aggiungere MFC a un progetto
ATL, ovvero aggiungere ATL a un progetto MFC.
Naturalmente, prima di arrivare a svolgere temi cosi` avanzati come
la fusione di due framework nello stesso progetto, e` meglio avere una
ottima padronanza di ciascuno dei due framework in questione; se no,
seguendo una "ricetta di cucina" senza capire bene le questioni, si
rischia di fare solo un pastrocchio.  L'uno e/o l'altro framework si
possono
benissimo usare senza una perfetta comprensione dei loro meccanismi,
ma la fusione fra i due, secondo me, non e` cosi` semplice.
Alex