Vedi post precedenti: ActiveX e
ActiveX(2)
Finalmente "l'opera" è conclusa. Ma perchè questo sbattimento?
Lo scopo era quello di utilizzare controlli managed in ambiente non managed.
Nello specifico infilare un pannello c# dentro un form MFC (visual studio
6).
Ufficialmente la registrazione di un componente windows form come ActiveX non
è supportata. Le alternative ufficiali quindi non sono molte 
.
Microsoft supporta come contenitore di componenti .net windows forms (olltre
alle windows forms stesse) MFC 7.x (quindi versione .net) e internet explorer
5.01 o superiore (vedi).
La soluzione internet explorer proposta è decisamente insufficiente,
infatti funziona unicamente lavorando con un web server (costruendo la pagina ed
aprendola in locale i componenti non vengono visualizzati, la cosa funziona
invece correttamente se la pagina risiede su iis).
Ufficialmente quindi l'unica alternativa valida è compilare l'applicazione di
origine sotto .net come codice unmanaged (combattendo con errori e warning vari)
ed all'interno di questa non come oggetti ActiveX registrati ma come oggetti
managed ottenendo l'interfaccia COM IUnknown dal controllo windows forms, le
alternative per fare questo sono due:
- Use the CLR hosting COM objects in native code to host the CLR, create
the default AppDomain and create an instance of the UserControl in this
AppDomain. (vedi documento
Hosting Interfaces.doc nella directory Tool Developers Guide dell'SDK di .Net)
- Use Managed Extension to C++, directly create the UserControl with
"new MyControl()", and use the Marshal::GetObjectForIUnknown() to get the
IUnknown of the UserControl
Fonte: Active
Document Server and .NET FONT migration
La prima ipotesi consente di lasciare unmanaged tutto il
codice MFC del contenitore (riducendo però le possibilità di interazione, la
seconda comporta la necessità di compilare parte dell'applicazione MFC come
managed ottenendo però così l'accesso totale al controllo incluso.
Non contento delle possibilità ufficialmente supportate ho provato a
percorrere la strada dell'ActiveX. A questo punto si sono aperte altre
possibilità:
- ActiveX in MFC 6
- ActiveX in Internet Explorer con CLSID (da includere a sua volta in MFC
6)
- ActiveX in ATL (.NET) e ATL come ActiveX in MFC 6.
Ho testato le tre possibilità (non supportate da Microsoft). I test
hanno portato a concludere che la 1 risulta molto instabile. La 2 è
semplice da implementare e decisamente stabile (anche se molto limitato per
quanto riguarda la comunicazione tra il contenitore e l'ActiveX), la 3 risulta
incredibilmente stabile e completa ma decisamente complessa da implementare.
Traendo rapide conclusioni, la soluzione preferibile rimane ovviamente quella
proposta da Microsoft, ma se il tempo stringe ed è necessaria una soluzione
molto rapida l'utilizzo di Controlli Windows Forms dentro Internet Explorer come
ActiveX non è da disdegnare (semprechè non sia necessario un alto livello di
comunicazione). La 3 pur risultando stabile e completa richiede uno sforzo
implementativo che forse è più utile dirottare sulla soluzione Microsoft.
powered by IMHO 1.1 with Emoticon Formatter