VB6: Interaction avec un formulaire invisible

Question

Donc, j'ai un formulaire en VB qui est visible sauf lorsque le programme est démarré silencieusement, auquel cas le formulaire est toujours chargé mais les interactions sont faites de manière programmée. Cependant, dans un petit nombre de cas, je veux que les formulaires créés à l'intérieur du formulaire invisible soient visibles. Quel est le meilleur moyen d'accomplir cela, idéalement sans créer de nouveaux formulaires. Certaines idées auxquelles j'ai pensé mais je n'aime vraiment pas :

• Créer un nouveau formulaire, passer le hwnd de ce formulaire pour qu'il héberge des fenêtres applicables. Très facile à faire, probablement assez flexible. Toujours moche.

• Appeler manuellement le formulaire visible, extraire les valeurs, transmettre les données remplies par l'utilisateur au formulaire invisible. Cette solution est probablement la plus simple, mais c'est aussi un hack. C'est une solution terrible si elle est utilisée pour plus qu'un petit nombre de formulaires, mais elle le fera probablement.

• Créer une nouvelle classe, refactoriser les formulaires pour être déclenchés par des événements.

• Définir le formulaire principal comme visible, mais détourner sa fonction de chargement pour qu'il n'affiche rien en réalité.

• Ne pas utiliser du tout le formulaire invisible, refactoriser le code pour mieux séparer la fonctionnalité du formulaire de l'utilisation. En vérité, c'est déjà largement vrai, mais je ne vois pas de moyen de le faire complètement sans un certaine répétition avec la manière dont les classes sont utilisées, car je finirai par avoir besoin de deux classes différentes qui incluent la même fonction. Probablement la solution la plus idéaliste, cependant.

• Ce que j'ai fini par faire : Intégrer un appel shell execute à l'endroit concerné qui lance une nouvelle instance d'une copie du programme qui a été compilée avec différents drapeaux. Ce n'est pas aussi mauvais que cela puisse paraitre. Une partie du problème avec toute autre solution est que CHAQUE fois que je veux ajouter une nouvelle interface utilisateur à mon code, je dois créer une nouvelle classe de contrôleur qui gère les événements pertinents différemment. La majorité de l'interface du programme est déjà séparée de son implémentation, mais créer une nouvelle interface utilisateur nécessite l'ajout de gestionnaires d'événements supplémentaires, et ainsi de suite. De toute évidence, cela nécessiterait probablement seulement environ 3 gestionnaires d'événements pour demander à l'utilisateur d'entrer des informations lorsque les événements sont déclenchés.

Éditer : Dans une certaine mesure, j'ai mal exprimé mon problème : Le problème est que je veux récupérer une partie de mon interface utilisateur existante, mais pas toute. Ainsi, rendre invisibles les parties que je ne veux pas que l'utilisateur voie mais rendre visibles les menus qui apparaissent. Découpler les composants individuels de l'iinterface utilisateur augmentera probablement la complexité du programme.

Answer 1

La dernière option est préférable; après le refactoring, il ne devrait pas y avoir de code redondant

bidouiller avec des formulaires invisibles est un très bon indicateur de la nécessité de refactoring!

Answer 2

Je recommande également la dernière option. Ce que je ferais pour implémenter en toute sécurité avec le moins de changements possible est le suivant.

Faites une sauvegarde ou vérifiez tout dans votre contrôle de source et créez une branche.

Créez un nouveau projet de DLL ActiveX. Je le nommerais une variante de UI_Controller

Note: Un nouveau projet vous forcera à identifier les dépendances cachées dans l'EXE.

Faites référence à tout ce que l'EXE est actuellement.

Faites en sorte que le projet EXE fasse référence au UI_Controller.

Créez une classe pour chaque formulaire principal de l'application.

Copiez les dialogues mineurs dans le DLL UI_Controller.

Pour chaque formulaire, créez une classe d'interface dans le DLL UI_Controller (le formulaire implémentera cela)

Par exemple, si vous avez six formulaires principaux, vous aurez alors six interfaces de formulaire et six classes de contrôleur.

Parcourez le formulaire pour chaque procédure et événement, COPIEZ la procédure dans la classe UI Controller et assurez-vous qu'elle est publique.

Assurez-vous que chaque classe de contrôleur a une procédure Init.

Cependant, il y a une exception, et c'est si le code ne traite que d'autres contrôles et du formulaire. Par exemple, l'événement de redimensionnement réorganisant le code. La raison en est que c'est une logique spécifique à ce style de formulaire. Un formulaire ou une UI différent utilisant la classe du contrôleur aura un algorithme de redimensionnement différent, il n'a donc aucun sens de déplacer ce code. Vous devrez utiliser votre meilleur jugement.

Retournez aux classes de contrôleur. Beaucoup des procédures devront faire référence à des éléments sur un formulaire spécifique ou déclencher des événements sur un formulaire. Rédigez un en-tête de sous-routine ou une fonction dans votre classe d'interface de formulaire pour permettre à cet événement de se produire ou pour récupérer les informations nécessaires. Remarquez que si vous trouvez que les mêmes actions sont regroupées ou que les mêmes séries d'informations sont récupérées, envisagez de ne créer qu'une seule sous-routine au lieu de plusieurs.

Changez toutes les références directes à un formulaire en un appel à l'interface.

Faites en sorte que vos formulaires principaux implémentent chaque interface. Créez une classe GlobalMultiUse dans votre DLL UI Controller qui permet à l'EXE d'enregistrer chaque formulaire avec son contrôleur. Les sous-routines d'enregistrement ne doivent accepter qu'un objet de l'interface de formulaire. Dans votre initialisation de l'application, passez chaque formulaire principal à la fonction d'enregistrement appropriée avant de faire quoi que ce soit d'autre.

Exécutez votre projet et corrigez toutes les erreurs. Notez que la fonction réelle de votre logiciel devrait rester la même car vous n'auriez fait que copier et implémenter.

Lorsque le logiciel fonctionne sans erreurs. Enregistrez-le dans votre contrôle de source ou faites une sauvegarde.

Commencez par remplacer chaque procédure d'UN de vos formulaires principaux par un appel à la méthode correspondante de votre formulaire de contrôleur. Si un autre formulaire appelle quelque chose sur le formulaire sur lequel vous travaillez, basculez cet appel vers le contrôleur.

Lorsque vous avez fini, assurez-vous que l'initialisation du formulaire du contrôleur est appelée dans la section d'initialisation de votre application. Vous devrez peut-être passer à l'utilisation d'un Sub Main pour que cela fonctionne.

Lorsque cela fonctionne correctement, travaillez sur un autre formulaire. Continuez ainsi jusqu'à ce que tous les formulaires soient convertis.

Nettoyez tout ce qui n'est pas utilisé.

Testez et si cela réussit, vous avez terminé.

Vous avez maintenant une application où vous pouvez arracher l'interface utilisateur actuelle et la remplacer par n'importe quoi qui implémente les interfaces de formulaire. Vous pouvez avoir un EXE invisible, un EXE de test unitaire et votre EXE régulier.

Vous devrez décider ce qui est le mieux pour vous en fonction de la complexité de votre application. Vous pouvez effectuer une conversion partielle où vous donnez à un ou deux formulaires une classe de contrôleur.