Discussion :

[sone47]

Bonjour a tous,

Est il possible sur une appli MFC de la passer en mode batch afin de camoufler l'IHM et pouvoir lancer des traitements habituellement liés à la view en direct.
Pour l'instant dans le InitInstance, selon les arguments j'utilise un m_pMainWnd->ShowWindow(ShowCmd) afin de la camoufler ou non (est ce la bonne méthode?).

Par contre je dois en batch lier certains arguments à des traitements liés initialement sur des actions IHM de ma classe CMyView: OnXxxYyy()

Est il possible de taper directement dans mon instance CMyView ou doit on déporter les traitements de cette classe ?
Si oui comment la récupérer dans mon initInstance de ma CMyApp ?

Merci d'avance.

[bacelar]

Là, vous nagez à contre-courant.
Les MFC c'est surtout pour des applications graphiques.

Pour faire le genre de truc que vous voulez faire, c'est le genre de chose qu'on planifie un minimum à l'avance.

Si vous avez planifié à l'avance, ou que vous utilisez l'approche TDD, vous devriez avoir une couche logicielle qui fait son travail sans aucune IHM, parce que faire des tests automatiques sur une IHM, c'est chiant.

j'utilise un m_pMainWnd->ShowWindow(ShowCmd) afin de la camoufler ou non (est ce la bonne méthode?).

Oui, très bonne, c'est même un mécanisme standard des MFC.

Il y a pas mal de mécanisme des View qui se base sur une pompe à message d'une fenêtre graphique.
Il serait bien plus fiable de n'avoir du code métier que dans la couche business de l'application.

Si vous pouvez rapatrier le code opérationnel dans la partie du code non dépendante des MFC, cela bien plus maintenable à long terme. Vous pourrez avoir une vraie application console.

[sone47]

Merci bacelar pour votre retour,
Je suis conscient de nager à contre courant sur le principe,
mais malheureusement ceci porte sur une application de longue date ou dans la planification l'approche batch n'a pas été pensée.

J'ai bien évidemment pensé sortir les traitements liés aux action OnXXX dans les views pour pouvoir séparer routines métiers et IHM mais ceci modifie de manière profonde tout le code.
Et au vu du chantier et des risques liés, cette modification profonde n'est pas souhaitée...

J'ai réussi pour l'instant à lancer quelques routines liées aux vues de manière bricolée,
en castant le pointeur de la mainWin "m_pMainWnd" en un CMyView* dans mon initInstance.

A partir de cette vue CMyView je créé mes dialog de l'appli qui ne s'affichent pas vu que l'appli est en showWindow(False).
Je lance les traitements sur les dialog comme s'il y avait eu un OnMyAction() (le code métier étant directement porté par les dialog) puis je les détruits.

Pour l'instant ça tourne, et me permet de voir que même en showOff cela ne bride pas le fonctionnement.
Maintenant j'aimerais cadrer tout ça de manière propre, mais n'étant pas familier des applis MFC, je ne sais pas si ceci se pratique et les risques éventuels.

Merci pour votre retour.

[Médinoc]

Le gros problème, c'est qu'à la première erreur venue, une application graphique non-prévue pour un fonctionnement "silencieux" affiche une boîte de dialogue.

Ce qui est mortel pour une application lancée depuis une tâche planifiée, car celles-ci s'exécutent dans un bureau caché qui ne verra jamais une souris.

Franchement, extraire la logique, et la placer dans une bibliothèque, reste la meilleure chose à faire.

[sone47]

Le gros problème, c'est qu'à la première erreur venue, une application graphique non-prévue pour un fonctionnement "silencieux" affiche une boîte de dialogue.

Ce qui est mortel pour une application lancée depuis une tâche planifiée, car celles-ci s'exécutent dans un bureau caché qui ne verra jamais une souris.

Ok c'est un point plus qu'important, et n'y a t'il pas moyen de configurer ceci pour avoir un autre fonctionnement que cette boite de dialog ? Un arrêt simple.

Franchement, extraire la logique, et la placer dans une bibliothèque, reste la meilleure chose à faire.

Je suis d'accord avec toi, mais ce genre de décision ne m'appartient pas, d'où ma venu sur le sujet, histoire d'avoir quelque chose de "correct".

[Médinoc]

Ok c'est un point plus qu'important, et n'y a t'il pas moyen de configurer ceci pour avoir un autre fonctionnement que cette boite de dialog ? Un arrêt simple.

Ben si tu as le code source du programme, tu peux éplucher tous ses appels à MessageBox() ou AfxMessageBox() et les remplacer par une fonction qui abort() à la place si tu es en mode batch, mais à part ça...

Sans compter les autres boîtes de dialogue du programme...

[bacelar]

De tout façon, on restera dans le bricolage.

Une stratégie de fainéant est de faire des MACRO pour redéfinir les ces MessageBox et autres fenêtre d'erreur, mais c'est vraiment du bricolage du dimanche.
On peut aussi passer par du détournement d'appel système via des système comme Detours ( http://research.microsoft.com/en-us/projects/detours/) mais c'est juste du bricolage de haut-vol.

Un truc pour permettre une mise au point "on field", c'est de faire un watch_dog qui vérifiera que votre programme ne crée pas de fenêtre, se ferme bien, s’exécute "correctement", etc...
Vous pouvez coupler ce watch_dog à des compteurs de performance et il pourrait aussi tenter de corriger les dysfonctionnement connus.

Mais franchement, un refonte de l'application est largement préférable.
Si la refonte est compliquée, c'est que les principes de codages MFC n'ont pas été respectés et que l'application devrait être refondue même dans le cas non-batch.

Rouler avec une roue crevée coute plus chère qu'une roue neuve.

[sone47]

Merci pour vos retours,

J'ai capté les différents appels au messageBox, il n'y en avait pas des masses par chance.
Ca reste du bricolage mais bon ce sont les consignes.

Aussi petite question supplémentaire.
Pour cacher la fenetre j'utilise donc: m_pMainWnd->ShowWindow(FALSE);
Par contre dans l'initInstance apres le ProcessShellCommand l'application s'ouvre automatiquement, derriere je cache la fenetre mais du coup à l'exécution j'ai quand meme une rapide apparition.

Y a til un parametre qui permette d'avoir le showWindow a FALSE par défaut histoire de ne pas avoir d'ouverture sur certaines fonction ?
(je l'ai sur le ProcessShellCommand et dans le OpenDocumentFile)

Merci d'avance

[bacelar]

Le plus simple, c'est de "truander" les MFC en changeant les paramètres de la ligne de commande avant qu'elles s'en servent.
https://msdn.microsoft.com/en-us/library/84dxkf0w.aspx

[sone47]

Ok merci a tous pour vos retours.
J'ai donc gardé la ligne initiale et encapsuler les créations de msgbox selon le contexte.

Merci bacelar je vais regarder ça