[MFC] CWinApp et CDialog

Bonjour,
Je reprend une application dont le "coeur" peut trés bien se passer d'interface graphique voire d'interface console. Mais visiblement, elle à été développer en même temps que son interface MFC. C'est à dire, que tout est mélangé, une grande quantité de code qui n'a rien à voir avec l'interface, se trouve implémanter dans des methodes de la classe CDialog (enfin une héritière).
par exemple un dialogue avec un port serie ou une mise à jour dans une bdd, etc...
Bref, l'application actuelle ne peut pas vivre sans son interface MFC. Connaissez vous un moyen assez fiable mais raisonnable pour mieux structurer ce bazar. Je pensais dans un premier temps, externaliser certaines choses dans la classe CWinApp, qui elle-même peut éventuellement instancier une interface graphique. Es-ce une bonne idée.
D'autre piste. Merci de toutes aides ou sugestions.

bienvenu au club, je suis salarié depuis 6 mois, c'est mon premier job en tant que dev C++, et le bébé qu'on m'a refilé est exactement comme chez toi. (son auteur m'a meme avoué avoir scindé le code source de la Dlg en 3 fichiers pour eviter d'avoir un CPP de trop grande taille, je te laisse donc imaginer le bazard qu'il y a la dedans.

Et comme toi j'aimerai bien dans l'ideal, ne laisser que ce qui concerne l'interface dans la Dlg (omportement des control, appel aux fonctions membre de classes structurées (voir exemple plus bas), et mettre sous classe tout le reste. Malheureusement, il y en aurait pour des mois, et le patron ne veut pas financer un tel travail, alors je suis obligé de travailler avec :cry:

Dans les autres projets que j'ai commencé, j'ai fais comme tu dis.

J'essaye de faire des classes structurées, puis dans CWinApp je crée des membres du type de ces classes. L'avantage, c'est que du coup dans n'importe quelle Dlg, je peux acceder à mes classes au travers de theApp (l'instance unique de CWinApp).

Apres tout dépend de comment tu veux restructurer ton appli. Par rapport à ce que tu dis, je pourrai imaginer un truc du genre :

http://img78.imageshack.us/img78/7128/demo5wn.th.jpg

Tu aurait donc ta boite de dialogue principale qui par exemple si elle veut afficher la boite de dialogue pour configurer le port com 1 ferait un :

theApp.m_rs232Manager.m_tbCom[1].ShowConfigDialogue();

ou pour envoyer une commande au port Com2 :

theApp.m_rs232Manager.m_tbCom[2].SendCmd("AFK");

Mais bon tout ca n'est que mon avis de debutant. Si quelqu'un a des commentaires a faire sur tout ca, moi aussi je suis prenneur, d'autant plus que je vais d'ici la fin de la semaine gerer moi aussi des ports com dans mon projet MFC.

Merci de m'avoir donné ton point de vue. Je me suis bien marré en lisant ton post. Ton cas à l'air encore plus délicat que le mien. Punaise j'adore notre job!

A t-on avis encore, où dois je placer ma "main loop". CWinApp implémente une méthode : Run(); Es-ce le bon encroit ?

J'ai bien essayé, mais hélas le wizard VC++ me contruit le bazar de la manière suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

nResponse = dlg.DoModal();   if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel }

---

L'application reste bloqué sur le DoModal();
Elle me redonne la main que lorsque le dialoque se ferme. Ensuite je rentre en effet dans ma méthode Run(). Hélas c'est trop tard! Le dialogue est fermé.
Dingue!

Citation:

---

Envoyé par teddy311

Merci de m'avoir donné ton point de vue. Je me suis bien marré en lisant ton post. Ton cas à l'air encore plus délicat que le mien. Punaise j'adore notre job!

1)A t-on avis encore, où dois je placer ma "main loop". CWinApp implémente une méthode : Run(); Es-ce le bon encroit ?

2)J'ai bien essayé, mais hélas le wizard VC++ me contruit le bazar de la manière suivante:


3)L'application reste bloqué sur le DoModal();
Elle me redonne la main que lorsque le dialoque se ferme. Ensuite je rentre en effet dans ma méthode Run(). Hélas c'est trop tard! Le dialogue est fermé.
Dingue!

---

salut,
1) surtout pas ...
c'est un programme evenementiel (en comparaison avec un prog en mode console),la main loop c'est les MFC qui la gere pour dispatcher les messages.
tu ne dois pas avoir besoin de mainloop sinon tu te trompes de nature de programme .
2) c'est normal et c'est la generation standard pour une application de type boîte de dialogue.
3) c'est normal pour une application boîte de dialogue.

vouloir separer l'objet metier de l'interface c'est bien ,ça a toutefois des limites mais surtout avant tout il faut deja bien connaitre le systeme dans lequel tu developpes pour ne pas se tromper de sujet...

:D

pour le placement de la loop, je ne suis pas expert donc je ne préfére rien dire. Mais bon, je pense qu'il ne faut pas non plus essayer de réinventer la roue systematiquement, on a deja bien assez de ligne à coder pour faire des choses toutes bete en C++, si en plus il faut restructurer les MFC....

pour ta DLg, c'est normal que ca bloque vue que DoModal est une fonction bloquante, elle libere la main une fois que l'utilisateur à refermé la boite (voir msdn CDialog::Domodal) si tu veux que ca ne bloque pas, il faut faire une boite amodale (je te rassure tu pourra assez facilement et rapidement rendre ta boite modale, amodale), regarde dans la faq visual sur ce site tu trouvera une mine d'infos interressante, dont, comment faire une boite amodale.

de tete c'est en utilisant la fonction create pour l'afficher, et destroyjenesaisplusquoi() pour la détruire et donc cacher. (biensur y a aussi la fonction ShowDialog() pour cacher et afficher une Dlg deja existante sans avcoir à la recréer ou détruire.

D'accord, je crois avoir compris ce que tu voulais dire.
Et puis en effet, je ne maitrise pas du tout les MFC, aucunes api graphique d'ailleur.

Dans mon projet, il me faut emettre de maniere cyclique, une trame de quelques octets sur le port serie (Dès le lancement de l'application et on arrete lors de la fermeture) Ou verriez vous cette portion de code ?

Citation:

---

Envoyé par teddy311

D'accord, je crois avoir compris ce que tu voulais dire.
Et puis en effet, je ne maitrise pas du tout les MFC, aucunes api graphique d'ailleur.

Dans mon projet, il me faut emettre de maniere cyclique, une trame de quelques octets sur le port serie (Dès le lancement de l'application et on arrete lors de la fermeture) Ou verriez vous cette portion de code ?

---

ça peut se faire avec un timer ,(voir faq)
et si le traitement est plus critique eventuellement avec un thread en utilisant
un objet event pour la tempo.
mais le timer me semble plus facile dans ton cas.
:D

le RS232 c'est tres lent, donc moi j'employerai un Timer (regarde dans la faq Visual sur ce site)
dans la classe CWinAppdans initinstance() avant le Domodal qui affiche ta Dlg principale, tu fais un SetTimer et apres le DoModal un KillTimer

enfin, un truc du genre quoi...

ca fonctionnera tres bien vu que tu n'est pas à 50ms pret.

Ah... les grands esprits se rencontrent :lol: :D

bon, j'essaye de faire comme ca et je vous tiens au courant.
merci à vous deux

Je peux encore compléter en disant que j'ai eu aussi les mêmes problèmes, et que si vous reprenez mon sujet 2 mois avant, vous seriez capables de faire des miracles.
sujet MFC Problème Threads + Timers
C'est du code amélioré repris directement de la FAQ.

Pour ce qui est de l'évolution de votre code barbare codé par des barbares, utilisez des classes en singleton (design pattern) et appelez les ou vous le souhaitez. L'instance est unique et on ne peut pas se tromper.

J'ai un client/serveur codé de cette manière et le code de traitement n'est pas dans les fichiers MFC.

Bon courage en tous cas.

Bon, ca démarre mal...
J'ai bien initiliser un timer d'id "1" dans la methode suivante:

Code:

---

1 2 3 4 5 6

BOOL CProjectDlg::OnInitDialog() { ... SetTimer(1,200, NULL); ... }

---

viens ensuite la methode OnTimer

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void CProjectDlg::OnTimer(UINT nIDEvent) { switch(nIDEvent) { case 1: MessageBeep(0xFFFFFFFF); // Beep break; default: break; } CDialog::OnTimer(nIDEvent); }

---

defini automatiquement dans la classe par le wizard comme ceci :

Code:

---

afx_msg void OnTimer(UINT nIDEvent);

---

Hélas je ne rentre pas dans ma methode OnTimer .
Je suis passé à coté de quelque chose non ?

ALors la franchement, je ne vois pas.
tout semble correct

Fait un projet MFC type CDialogue tout neuf, juste avec un timer dans la Dlg qui lance un Beep(500,100);

histoire de comparer...
si ca marche dans ce projet nouveau, fait un clean sur ton projet barbare, puis recompile le.

tu utilise quel visual?

Salut . Je viens de trouver ce qui n'aller pas. Il me manquais une Handler (WM_TIMER) sur mon dialogue principal. Maintenant, cela semble fonctionner. Merci à tous pour votre aide.

ça veut donc dire que tu n'as pas generer le message avec l'assistant ...

:D

En fait, les précedents développeurs avaient déja du le placer. Avec mes manip, j'ai du le virer par inadvertance.