Discussion :

[totem]

Bonjour !


J'ai un petit soucis que je retrouve partout dans mon application : quand j'appelle une boite modale (CColorDialog, custom dialogs ou même les boites d'avertissement déclenchées par AfxMessageBox ou par une validation de donnée qui rate), et bien ces petites boites ne s'affichent pas.
En fait, ma fenêtre principale se grise et se bloque bien, ce qui est le comportement d'une fenetre mère qui affiche une boite modale, mais il faut que j'appuie sur ALT pour que la boite s'affiche.
Je ne pense pas que ce soit le parent qui soit mal spécifié car je construis bien toutes mes boites en passant le CWnd* de la fenetre parente à la construction..
Avez-vous une petite idée d'où pourrait venir ce problème ?

merci !

[totem]

Bon alors j'ai un peu avancé dans ce bug, et maintenant je peux dire qu'il n'arrive que quand j'ai au moins une fenetre MDIChild d'ouverte par mon appli. C'est à dire que ce serait les fenêtre MDI filles qui bloqueraient les popup modales..
L'affichage d'une fenetre modale déclenche t-il un message que je pourrait exploiter, ou y a-til des propriétés à fournir à une fenêtre fille pour qu'elle ne bloque pas les fenetres modales ?

[farscape]

salut,
étrange ton probléme ...
essaye de mettre AfxGetMainWnd() comme parent pour voir.

[totem]

ça bug vraiment là, j'ai plus accès à rien.
je vais tâtonner de mon côté, mais si vous avez des idées, elles seront les bienvenues

[farscape]

la boite de dialogue CAbout ( a propos de ) s'affiche correctement ?

[totem]

de la même façon, elle fonctionne quand j'ai une mainframe vide, mais si j'ouvre un nouveau document, c'est là que ça bloque.

[farscape]

tu as du faire quelque chose de spécial pour en arriver la...
tu me dis pas tout .
pas de thread ?
pas de timer ?
quelles sont les particularités de ces views ?, il doit forcement y en avoir cas dans un contexte normal ce cas fonctionne très bien ....

[totem]

oH oui en effet je fais pas mal de choses pas normales.
et non : pas de thread, pas de timer; désolé de pas avoir été précis.

Je pense que ça vient du fait que je ne connais pas assez la programmation windows, avec les DefWindProc et autres MessagePump je m'embrouille bien. Qui plus est je fais une application non pas en EXE mais dans une DLL, avec ça propre pompe à message.

[farscape]

ben voila ...
ta pompe a messages ne laisse pas respirer le reste de l'application en autre les boites de dialogues....

[totem]

Bon merci je soupçonnais déjà ce bricolage d'être à la base de bien de mes maux. Je verrais comment optimiser ça plus tard.

et alors comment qu'on fait respirer ?

il faut jouer avec les OnIdle() ?
Utiliser PeekMessage plutot que GetMessage ?
Faire une pompe à message dans chaque classe de fenetre plutot qu'une seule dans le CWinApp-derived ?

autant de pistes qui me poussent à m'occuper d'autres problèmes d'abord ..

[farscape]

la solution passe peut etre par associer un thread a tes dialogues...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
 
class CWnd;
 
template <class ModalDialog>class NonModalDialog
: public ModalDialog
{
public :
 NonModalDialog( CWnd *pParent )
 : ModalDialog( pParent ) { }
 
 virtual int DoModal();
 virtual void EndModalLoop( int );
protected:
 int m_nStillActive;
};
 
template <class ModalDialog>
inline int NonModalDialog<ModalDialog>::DoModal()
{
 MSG            l_objMessage;
 CWinThread*    l_pThread = AfxGetThread();
 
 ASSERT_VALID( l_pThread );
 
 Create( ModalDialog::IDD );
 ShowWindow( SW_SHOW );
 m_nStillActive = 1;
 
 //--------- Thanks to Microsoft. This block
 //--------- is from CWinThread::Run
 // from Thrdcore.cpp, with appropriate changes.
 ASSERT_VALID(this);
 // for tracking the idle time state
 BOOL l_nIdle = TRUE;
 LONG l_nIdleCount = 0;
 
 // acquire and dispatch messages until
 // a WM_QUIT message is received,
 // or the dialog box is closed.
 for (;;)
 {
  // phase1: check to see if we can do idle work
  while( l_nIdle && !::PeekMessage( &l_objMessage,
                                    NULL,
                                    NULL,
                                    NULL,
                                    PM_NOREMOVE ) )
  {
   // call OnIdle while in bIdle state
   if( !l_pThread->OnIdle( l_nIdleCount++ ) )
    l_nIdle = FALSE; // assume "no idle" state
  }
 
  // phase2: pump messages while available
  do
  {
   // Relent control back to Windows if the dialog
   // box has closed.
   if( !m_nStillActive )
    return m_nModalResult;
 
   if( l_objMessage.message == WM_SYSCOMMAND
   && l_objMessage.wParam == SC_CLOSE )
    OnCancel();    // Close the dialog box first.
 
   // pump message, but quit on WM_QUIT
   if( !l_pThread->PumpMessage() )
    return l_pThread->ExitInstance();
 
   // reset "no idle" state after pumping
   // "normal" message
   if( l_pThread->IsIdleMessage( &l_objMessage ) )
    l_nIdle = TRUE, l_nIdleCount = 0;
  } while( ::PeekMessage( &l_objMessage,
                          NULL,
                          NULL,
                          NULL,
                          PM_NOREMOVE ) );
 }
 ASSERT(FALSE);  // not reachable
 //---------------------
}
 
template <class ModalDialog>inline void
NonModalDialog<ModalDialog>::EndModalLoop(int p_nResult)
{
 m_nStillActive = 0;
 ModalDialog::EndModalLoop( p_nResult );
}

utilisation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
NonModalDialog<MyDlg>myDlg( AfxGetMainWnd() );
myDlg.DoModal();

[totem]

wow !

bon je tiendrais la discussion au courant dès que j'aurai essayé ta solution (qui me paraît joliment complexe, mais pas compliquée)

Merci farscape !

[totem]

Ok !


Donc ça fonctionne plutôt pas mal ma foi !
il y a juste que je ne peux pas apppliquer ce subterfuge aux fenetres modales genre AfxMessageBox ou même celles qui sont appelées en interne lors d'un DoDataExchange qui rate Mais au vu du travail à faire je me contente largement d'une moitié de problème résolue, pour l'instant.

En tout cas bravo j'ai rien eu à changer quasiment

[totem]

Voilà je me remets au travail sur cette question des fenêtres modales qui ne s'affichent pas, et j'ai décidé de résoudre un problème à la fois. J'en suis là : grâce à ma pompe à message, j'arrive à isoler les codes des messages qui sont envoyés juste avant l'affichage de chaque popup modale avec un code du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
// dans le code de la pompe à message, 'msg' est récupéré par PeekMessage
switch( msg.message ){
 
	case 0x00000102 : fprintf(stderr, "DDE foireux\n") ;
					break ;
 
	case 0x000000a1 : fprintf(stderr,"enregistrer avant de fermer\n") ;
					break ;
}

Après tests je reçois bien un message 0x00000102 à chaque fois que je rentre une valeur érronée dans un champ surveillé par une validation (du type DDV_MinMaxDouble(...)), erreur qui provoque l'appel d'un des types de fenêtre qui sont là mais ne s'affichent pas. Et donc ma question c'est : quelqu'un connait-il le moyen de faire la correspondance entre un code de message et une espèce d'explication/documentation sur le message lui-même ?

parceque dans ce cas j'essaierai d'exploiter les possibles wParam/lParam du message pour forcer l'affichage (ou je sais pas quels arguments accepte ce message..)


merci !

[farscape]

salut,
je persiste a penser que si tu avais fait une dll d'extensions MFC tu n'aurais pas ces problèmes de pompe a messages ....

[totem]

hmm certes je te crois !!
mais le problème c'est qu'on me demande de faire une DLL qui sera lancée depuis un autre programme écrit dans un langage X et auquel je n'ai point accès.


edit : enfin tu as raison, c'est un gros soucis il faut que je leur explique ça ça résoudrait probablement pas mal de problèmes. merci farscape pour tes réponses