Je veux créer un thread après la création d'une boîte de dialogue dans MFC. Existe-t-il une fonction que Windows a fourni et s'appelle automatiquement après Oninitdialog code> afin que je puisse créer mon fil à l'intérieur? P>
4 Réponses :
Pourquoi ne pouvez-vous pas créer votre fil là-bas? P> Oninitdialog () code> est la fonction principale appelée à l'initialisation (en réaction à
wm_create code>). p>
Je crée deux threads à l'intérieur de la fonction ontitidialog, mais lorsque j'exécute que la boîte de dialogue se trouve très lentement. Je crée un fil à l'intérieur de l'Ontimer I.e après 5 ms heure lorsque la boîte de dialogue formée, le thread commencera que cela fonctionne bien. Je pensais donc à la création de fil dans la minuterie s'il y a une autre fonction qui a appelé après Dialo est créée, je peux mettre mon code là-bas. Certaines fonctionnalités existent-elles?
N'est-ce pas oninitdialog code> appelé réaction à
wm_initdialog code>?
Vous pouvez simplement créer votre fil dans la fonction Si vous souhaitez obtenir votre boîte de dialogue à l'écran avant em> Vous créez le fil, vous pouvez simplement le montrer manuellement à l'aide du Voir aussi ce message par Raymond Chen: en attente jusqu'à ce que la boîte de dialogue soit affichée avant de faire quelque chose p> p> oninitdialog code>. Il n'y a aucune raison de surcharger les choses en allant et en recherchant une fonction différente ou en fractionnement de votre code d'initialisation en deux morceaux. (Il n'y a pas non plus em> aucune fonction de ce type, car il n'y a pas de message Windows correspondant envoyé.)
showwindow Code> fonction
. Par exemple: p>
J'ai trouvé que je devais aussi appeler centrewindow () code> car l'appelant showwindow a abouti à la boîte de dialogue en haut à gauche.
@klox hmm, qui ne devrait pas être nécessaire. Les dialogues sont automatiquement centrées sur leur propriétaire Windows. Cela se produit dans une fonction MFC interne, _afxpostinitdialog code>, qui fonctionne après
Oninitdialog code>.
_afxpostinitdialog code> appelle en fait
CentreWindow code> Si la fonction
Oninitdialog code> ne modifie pas les coordonnées de la boîte de dialogue. Mais l'appelant explicitement ne fera pas de mal, non plus, tout ce qui fonctionne. Assurez-vous simplement que vous vous centrez dans un endroit raisonnable, en tenant compte des systèmes multi-surveillants. Toujours centré sur l'affichage principal serait la mauvaise décision. :-)
Je n'ai pas de fenêtre de propriétaire (la boîte de dialogue est la seule fenêtre), mais votre description aide à expliquer le changement de comportement que je vois.
J'ai changé la priorité du fil en dessous de la normale et lorsque le thread est exécuté pour la première fois, je règle le thread au prieuré normal. Cela fonctionne bien. Merci pour votre réponse. P>
Après de nombreuses années de sentiment insatisfaisant de la solution ontimer pour dessiner des graphiques de première vue dans une application de dialogue MFC (une aire de jeux préférée), cela semblait être une belle solution simple: -
Une minuterie signifiait que l'application était en vie pendant un certain temps avant que les graphiques ne soient arrivés, et apparemment hscrolls soit priorisé pour se produire juste après le message WM_Paint qui effacerait un élément d'image à son état vide, supprimant tout ce qui a été tiré. Pendant Initdialog. P>
BOOL CSpecDlg::OnInitDialog() { ... PostMessage(WM_HSCROLL,0, (LPARAM)NULL); return TRUE; // return TRUE unless you set the focus to a control } void CSpecDlg::OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar) { // TODO: Add your message handler code here and/or call default if (pScrollBar==NULL) { plot(); } CDialogEx::OnHScroll(nSBCode, nPos, pScrollBar); }