cs_Nephilim
Messages postés25Date d'inscriptionlundi 6 septembre 2004StatutMembreDernière intervention 4 octobre 2005
-
21 sept. 2005 à 16:53
cs_Nephilim
Messages postés25Date d'inscriptionlundi 6 septembre 2004StatutMembreDernière intervention 4 octobre 2005
-
22 sept. 2005 à 11:59
Salut à tous,
Je me permets de reposter la question, le pauvre petit gars qui l'avait posée a du passer innaperçu dans le grand trou du mois de mai et n'a jamais eu de réponse :-/
Problématique :
modifier un controle utilisateur .net de façon à le rendre accessible comme tout bon vieux activex.
But :
Réutiliser des controles .net évolués dans des solutions ne supportant pas encore ces controles, vb6 par exemple (c'était le problème d'origine), ou Allfusion Plex pour ma part.
Cause :
L'architecture COM étant progressivement abandonnée par micro$oft, il n'est plus possible (à priori) de créer directement des composants ActiveX par VB.Net. Les nouveaux composants, appelés "controles windows" (projet de type "Bibliothèque de contrôles windows", fonctionnent de façon assez similaire mais ne sont plus visibles en tant que contrôle activex, on ne peut donc les réutiliser que dans des solutions .net ...
C'est un peu chiant, pour ma part j'ai plus de 2000 lignes de code en VB.NET dans mon composant, et ça me saoulerait un peu de devoir les repasser en VB6, sans compter le fait qu'un paquet de librairies risquent de poser problème (adodb, adomd, axowc10 compilé "maison" ...).
Solution:
A priori il exist(ait) une méthode sur la Beta1 vs.net qui permettait de mapper des fonctions standard COM ("ComRegisterFunction" etc.) de façon à simuler le comportement d'un activex standard. D'après ce que j'ai lu, cette méthode ne fonctionnait plus à partir de la Beta2 (krosoft abandonnant le support autour de COM), mais un illuminé s'est lancé dans l'aventure tout de même. Au final ça donne les méthodologies suivantes :
J'ai essayé de mixer un peu des trois, dans tous les sens, depuis deux jours, mais rien à faire ... si quelqu'un a déjà tenté et réussi avec succès à déclarer un controle utilisateur .net en le faisant passer pour un activex, je suis preneur ! Si il existe d'autres façons de faire pour réutiliser ces composants je suis preneur de conseils aussi, j'ai l'impression d'être dans une impasse par moments ...
Désolé pour la longueur.
Désolé pour l'imprécision.
Désolé pour l'intérêt tout relatif que représente le sujet.
Désolé en fait ... mais au secouuuurs :)
cboulas
Messages postés2641Date d'inscriptionmercredi 2 juin 2004StatutMembreDernière intervention 8 janvier 201416 21 sept. 2005 à 19:02
Salut, ce n'est qu'une idée, mais il faudrait peut-être intégrer une partie des DLL du framework à votre projet, puis y faire appel au lancement du projet, qui celui-ci s'en servira pour loader le contrôle
Chris...
Web : Firstruner - eMail : [mailto:support@firstruner.com Support]&
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_Nephilim
Messages postés25Date d'inscriptionlundi 6 septembre 2004StatutMembreDernière intervention 4 octobre 2005 22 sept. 2005 à 10:34
Salut Chris,
La supposition est parfaitement judicieuse ;)
Mais à priori il est plus "propre" d'installer tout bêtement le framework .net sur la machine qui exécute l'appli. Pour moi ça ne pose pas de problème de déploiement, c'est une appli distribuée par Citrix et il n'y a besoin d'installer qu'une machine : le serveur.
En plus je n'en suis pas là, l'objectif pour l'instant est de faire tourner un contrôle avec une bête propriété, juste pour prouver que c'est possible ... je verrai après pour faire tourner le -vrai- module :)
Mais ça ne fonctionne toujours pas :( J'ai bien une assembly "strong named" et chargée dans le cache global, des méthodes exposées comme il faut, des fonctions standard d'enregistrement COM, une interface reconnue par le système et déclarée dans la base de registres, et même la librairie de types est accessible, mais toujours pas d'activex visible dans les listes "officielles" de controles COM ... je crois que je vais devoir me fader la conversion en VB6 :(
Ce qui est désolant c'est que finalement, toutes les méthodes "magiques" décrites par des gars qui annoncent être parvenus ("tout simplement parceque .net c'est génial") à charger des composants s'avèrent incomplètes. Ils oublient la plupart des déclarations d'interopérabilité, le plus dur donc, et je ne vois pas comment ils peuvent prétendre que leur code marche, à tout les coups ils ne l'ont même pas testé :-/
Ce qui est encore plus désolant c'est l'insondable capacité de microsoft à abandonner des technos en cours de route sans assurer la compatibilité de ce qui suit. Professionnellement c'est moyen ...