Discussion :

[crv2xx]

POUR UNE PROPOSITION DE FAQ

📄 RAPPORT TECHNIQUE — COMPORTEMENT INTERMITTENT D’UNE FORM VB6 PENDANT L’EXÉCUTION DE MODULES COM/OCX
Titre du rapport
Comportement intermittent : disparition / réapparition de la Form principale VB6 pendant l’exécution de modules COM/OCX
Auteur
Camille Harvey, développeur VB6
Architecte logiciel pédagogique
Duhamel-Ouest, Québec, Canada
Date
1er juillet 2026

Sytème
Le problème apparaît en interaction VB6-Widows 11.
Résumé
Une application Visual Basic 6 présente un comportement intermittent où la Form principale (nommée Maître) disparaît, se redessine ou se réactive involontairement pendant l’exécution d’une séquence de 14 étapes impliquant des modules COM/OCX/DLL.
Ce comportement n’est pas constant :
• il peut disparaître complètement après un redémarrage,
• puis réapparaître sans modification du code,
• ce qui suggère un événement externe au code VB6.
Des événements Windows (Resize, Activate) sont capturés dans la fenêtre Immediate, indiquant que la Form reçoit des messages non sollicités.
Contexte technique
• Application VB6 classique
• Form principale : Maître
• Séquence de 14 étapes exécutées via un bouton cmd_Click
• Utilisation de plusieurs modules COM, OCX et DLL
• Environnement Windows 10 / Windows 11
• Aucun code de redessin ou repositionnement dans les étapes
• Le problème survient pendant l’exécution de modules COM

Symptômes observés
Pendant l’exécution, la fenêtre Immediate affiche :
Code
Resize
Resize
Resize
Activate
Ces événements surviennent :
• sans interaction utilisateur,
• sans appel à Show, Hide, Visible, ZOrder, Move, etc.,
• sans changement de taille programmé,
• sans redessin demandé.
Ils semblent être envoyés par Windows, pas par le code VB6.
Caractère intermittent
Le problème :
• peut disparaître complètement au démarrage du système,
• peut réapparaître plus tard sans modification du code,
• ne survient pas à chaque exécution,
• semble dépendre de l’état du système ou du timing de chargement des composants COM.
Analyse technique
Le comportement correspond à une réinitialisation ou activation d’un composant COM/OCX/DLL, qui :
• modifie la fenêtre parent,
• envoie un message WM_SIZE,
• envoie un message WM_ACTIVATE,
• déclenche un redessin de la Form active,
• provoque un repositionnement automatique.

Ce type de message peut être envoyé par :
• un contrôle OCX qui se charge,
• un composant COM qui s’initialise,
• une DLL utilisant SetWindowPos,
• un module Excel COM,
• un changement de DPI ou de thème Windows,
• un événement système (USB, Bluetooth, etc.).
Le caractère intermittent confirme que le problème dépend :
• du timing de chargement des composants,
• de l’environnement Windows,
• de l’état du système au moment de l’exécution.
Comportement attendu
La Form principale ne devrait pas :
• recevoir de messages WM_SIZE ou WM_ACTIVATE pendant l’exécution,
• se redessiner sans demande explicite,
• se repositionner automatiquement,
• disparaître ou réapparaître involontairement.
Comportement réel
La Form principale :
• reçoit des messages Windows non sollicités,
• se redessine involontairement,
• se repositionne automatiquement,
• disparaît brièvement,
• réapparaît sans demande.
Impact
• perturbation visuelle,
• instabilité apparente de l’interface,
• mauvaise expérience utilisateur,
• difficulté à déployer l’application dans un environnement professionnel,
• impossibilité de prédire quand le problème se produira.
Questions pour analyse
1. Avez-vous déjà observé ce type de comportement intermittent dans VB6 ?
2. Est-ce lié à certains OCX/COM connus (MSComCtl, Excel COM, etc.) ?
3. Existe-t-il une manière fiable de neutraliser ces messages Windows sans subclassing ?
4. Est-ce un comportement connu du runtime VB6 sous Windows 10/11 ?
5. Une reproduction minimale serait-elle utile pour analyse ?
Conclusion
Le problème semble provenir d’un composant COM/OCX/DLL qui envoie des messages Windows à la Form active pendant l’exécution. Le caractère intermittent suggère un facteur externe au code VB6.
Une analyse communautaire ou une confirmation d’un comportement connu du runtime VB6 serait utile pour déterminer une solution fiable.

Je tente ave Copilot de trouver une solution depuis plusieurs jours mais en vain !

[Kimmyn]

Bonjour crv2xx,

Ça ressemble à du subclassing implicite venant d'un composant COM/OCX. Pistes possibles : certains contrôles Microsoft créent un handle de fenêtre invisible au chargement et peuvent renvoyer WM_SIZE/WM_ACTIVATE en différé ; Excel COM est aussi connu pour réactiver la fenêtre du process appelant lors de certains événements internes. Avant de te lancer dans du subclassing ce qui est risqué en VB6, utilise Spy++ (inclus avec Visual Studio) pour capturer l'émetteur exact des messages ça identifiera directement le composant en cause plutôt que de deviner depuis la fenêtre Immediate.

Apres je pense que une reproduction minimale aiderait bien à isoler le module fautif.

[crv2xx]

Merci Kimmyn - Votre commentaire est précieux; je vais l'analyser avec Copilot...