Bonjour !

J'ai une erreur d'exception lorsque j'exécute mon application. Je ne peux malheureusement pas vous transmettre le code.. Je vous demande juste si vous auriez des pistes qui pourrais m'aider à résoudre cette erreur. Je vous laisse en photo l'erreur (l'exception est dans le fichier afxwin2.inl.

Merci par avance pour votre aide !

-
Edité par YouminAir FPV 13 octobre 2020 à 9:16:31

Salut !

Tu utilises la méthode dans un CDialog::OnInitDialog() ? Si tu l'utilises avant d'initialiser la fenêtre, c'est une erreur qui peut apparaître.

Oui j'utilise bien cette méthode dans un CDialog::OnInitDialog(). Je regarde ton conseil ! MERCI

Je te transmets mon code avec l'initialisation pour que tu me dise ce que tu en penses

-
Edité par YouminAir FPV 13 octobre 2020 à 9:54:02

Plusieurs choses à redire :

- Déjà si tu débutes un nouveau projet, oublies les MFC et passe à Qt ! MFC n'est plus maintenu, et y'a plein de choses très relou avec ! 

- Dans le OnInitDialog, je pense que l'appel à GetClientRect ou GetWindowRect pose problème car la fenêtre est initialisée mais pas visible ... ouais je sais c'est bizarre, mais j'ai déjà eu ce problème.

- Pour corriger, je te conseil de surcharger la méthode OnShowWindow() et de mettre le code de CRect mainWindowRect à m_BottomMargin ... dans cette méthode.

J'ai récupéré un gros projet donc je vais essayer de continuer la dessus pour celui la mais merci pour le conseil, pour mon prochain projet je ne ferai pas l'erreur

Ensuite, je ne trouve pas la méthode OnShowWindow().. normal ?

Je débute un peu alors désolé pour les questions qui peuvent "bêtes"

-
Edité par YouminAir FPV 13 octobre 2020 à 10:26:13

C'est une méthode de la classe CDialog avec le message WM_SHOWWINDOW.

Tu peux la générer directement avec Visual Studio

Donc si j'ai bien compris, tu me conseil à la suite de la méthode OnInitDialog() de mettre une nouvelle méthode OnShowWindow() ?

Comment fait-on pour la générer ?..

J’essaie quelque chose :

Merci encore de prendre le temps pour m'expliquer

-
Edité par YouminAir FPV 13 octobre 2020 à 10:49:33

En gros, pour afficher une fenêtre en MFC, tu vas appeler la méthode DoModal(), et cette méthode va appeler dans un premier temps la méthode OnInitDialog() qui va initialiser ta fenêtre ainsi que ses composants. Ensuite la méthode ShowWindow() sera appelée lors de l'affichage de ta fenêtre (c'est la méthode appelée lorsque tu fais un ShowWindow(SW_SHOW) par exemple)

C'est des méthodes virtuelles qui ont un comportement par défaut, mais que tu peux surcharger pour en modifier/ajouter un comportement.

Dans visual studio, dans l'onglet propriétés, onglet message.

Ou alors, dans ton code :

Le .h

afx_msg void OnShowWindow(BOOL bShow, UINT nStatus);

Le .cpp

BEGIN_MESSAGE_MAP(Nom de ta classe, Parent)
    ...
    ...
    ...
   ON_WM_SHOWWINDOW()
END_MESSAGE_MAP()

void Nom de ta classe::OnShowWindow(BOOL bShow, UINT nStatus) {

    CDialog::OnShowWindow(bShow, nStatus);

    // Ton code ici

}

Je suis d'accord avec @Toniooo sur la "pertinence" des MFC.

>pose problème car la fenêtre est initialisée mais pas visible ... ouais je sais c'est bizarre, mais j'ai déjà eu ce problème.

Mais faut pas dire trop de bêtises sur les MFC non plus.

Quand on sait comment cela marche, il n'y a absolument rien de bizarre dans les MFC.

Les MFC n'est qu'une simple et très légère couche logicielle au-dessus du GDI de Win32 pour simplifier son utilisation, mais avec un niveau d'abstraction quasi nulle par rapport au GDI. Une "objectisation" à la truelle, pas vraiment plus, mais ça suffit à grandement simplifier l'utilisation de GDI.

Il faut donc avoir un minimum de connaissance de GDI/Win32 pour correctement utiliser les MFC.

Donc, il n'y a rien de "bizarre" dans "l’échec" de "GetClientRect" ou "GetWindowRect" à ce moment-là du cycle de vie de l'objet MFC.

Le GDI est entièrement géré par l'OS et on interagir avec via des handlers (pointeurs opaques) car c'est une API C vaguement "objetisé".

Dans le constructeur C++ des objets MFC, on ne demande pas directement une création de fenêtre au GDI, car il y a des choses à potentiellement configurer avant que le GDI enquille les messages WINDOWS vers les routines C/C++ (oui, il y a pas mal de code "C like" pour faire tenir le tout) des fenêtres MFC (styles des fenêtres, routines de callback de traitement de message, template de création des contrôles, les polices à utiliser, etc...). Dans les classes de fenêtre/contrôles MFC, il y a un champ de nom "m_hwnd" qui donne l'handler GDI de la fenêtre, si le runtime MFC a déjà jugé utile de contacter le GDI pour lui demander de créer le ou les composants gérés par le GDI (fenêtres, thèmes, icônes, menus, pointeurs de souris, capture de souris, etc...) ce champ n'est plus null et contient l'handler qui permet aux MFC de dialoguer avec le GDI.

https://docs.microsoft.com/fr-fr/cpp/mfc/reference/cwnd-class?view=vs-2019#getsafehwnd

Généralement, c'est au moment où on demande aux MFC d'afficher la fenêtre qu'elles prennent enfin la peine de contacter le GDI pour faire son taf.

Après, le GDI dispose de tout un système de message pour que le code client puisse intervenir à différent moment du processus de création de la fenêtre GDI (transparence, synchronisation des couleurs, calage des contrôles, etc...). C'est là où les "hacks" des MFC permettent aux fonctions que l'utilisateur a redéfini dans ses classes d'entrer dans la boucle. Les MFC et les GDI interagissent ensuite via l'émission et réception de messages sur les fenêtres GDI.

Les "BEGIN_MESSAGE_MAP/END_MESSAGE_MAP" et autres "ON_..." sont là pour faire le pont entre les messages envoyés aux fenêtres par le GDI/OS et votre code, en plus des redéfinitions dans les classes filles de la classe CCmdTarget des MFC. Les messages interviennent tout le long de la vie de la fenêtre GDI. Il y a une différence stricte entre la fenêtre instance C++ des MFC et la fenêtre gérée par le GDI/OS et c'est le champ m_hwnd qui sert de lien entre les 2.

A en croire la documentation:

https://docs.microsoft.com/fr-fr/cpp/mfc/reference/cwnd-class?view=vs-2019#onshowwindow

Les MFC n'ont pas jugées utile de rendre virtuelle (afx_msg <> virtual) la méthode OnShowWindow, Vous avez donc besoin d'utiliser "BEGIN_MESSAGE_MAP/END_MESSAGE_MAP + ON_WM_SHOWWINDOW()" pour "surcharger" cette fonction.

Je me suis certainement mal exprimé, mais le bizarre est surtout un ressentit au niveau de l'utilisateur. Je ne doute à aucun moment de l'efficacité ou de la pertinence des MFC. Si le choses sont réalisées ainsi, c'est qu'il y a forcément une raison et j'en suis conscient.

Je trouve juste perturbant qu'on ne puisse pas utiliser des méthodes sur un objet qu'on vient d'initialiser ... c'est comme si je créais un objet Rectangle avec l'appel de son constructeur, mais qu'ensuite j'étais dans l'impossibilité d'appeler sa méthode pour récupérer sa position ... ça va à l'encontre de tous ce qu'on apprend à un novice de la programmation.

L'erreur de l'OP est une erreur certainement banale pour un expert/confirmé MFC, mais elle peut être très difficile à catch et coûteuse en temps pour quelqu'un qui serait moins à l'aise avec !

Je ne critique pas tes réponses, @Toniooo, c'est juste pour éviter l'effet Mme Irma.

Quand on a appris à utiliser Win32/GDI avant les MFC, on voit les MFC juste comme un ensemble de petits trucs super pratique pour gagner beaucoup de temps de développement.

Après, quand on regarde ce machin avec un œil de développeur C++, bin il y a beaucoup de choses qui hérisse le poil, il y a pas à dire.

Mais bon, c'est un truc qui a été bricolé avant 1992, donc 6 avant même que le C++ soit standardisé.

Moi, j'ai un œil nostalgique et assez admiratif du travail des concepteurs/bricoleurs, car leur implémentation regorge de hack fabuleux comme des quasi-v_table bricolées avec des MACRO, du hooking de fenêtre, du super-classing, du sub-classing, des "protocoles" à la smallTalk ou Objective-C, des "Design Pattern" à la "Chaîne de responsabilité" ou "Commande" avant l'heure (Gang Of Four, je crois que c'est 1995) etc... juste pour carrosser cet effroyable GDI (d'un point de vue Objet j'entends).

J'ai fais une réponse assez détaillée pour que le PO ait quelques billes quand il sera obligé de creuser plus avant ses recherches. Oui, parce que sans connaissance préalable de Win32/GDI et un bon niveau en bidouille C/C++ (et donc pas en C++ orthodoxe), je trouve toute cette conception très casse-gueule et sa documentation très peu claire.