IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

[Windows 11] Fen�tre impossible � d�truire ? Probl�me de rafraichissement ?


Sujet :

C++

  1. #1
    Membre confirm�
    Profil pro
    Inscrit en
    F�vrier 2005
    Messages
    208
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 208
    Par d�faut [Windows 11] Fen�tre impossible � d�truire ? Probl�me de rafraichissement ?
    Bonjour � tous,

    Nostalgique du temps o� il �tait possible d'avoir du contenu HTML en fond d'�cran du bureau Windows, je cherche � reproduire ce comportement en cr�ant une application affichant une fen�tre entre le fond d'�cran et les ic�nes du bureau.
    Je programme en C++ (bon sang, bien 15 ans que j'y ai pas touch� 🤪 ) sous Windows 11 avec Visual Studio Code.

    Pour cr�er cette fen�tre, j'utilise cette technique de ninja : https://www.codeproject.com/Articles...n-Windows-plus.
    Le handle retourn� (wallpaper_hwnd) sert de parent � la fen�tre de mon application, cr��e gr�ce � la ligne suivante :

    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    HWND hwnd = CreateWindowEx( 0, CLASS_NAME, L"Ma fenêtre",  WS_CHILD | WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 800, 600, wallpaper_hwnd, NULL, hInstance, NULL );
    J'ai aussi ajout� une ic�ne dans la zone de notification avec un menu me permettant de quitter l'appli.
    Lorsque je clique sur 'Quitter', j'appelle la fermeture de ma fen�tre gr�ce au message suivant :

    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    PostMessage(hwnd, WM_CLOSE, 0, 0);
    La r�ception du message de fermeture 'WM_CLOSE' entraine l'ex�cution du code suivant :

    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    case WM_CLOSE:
    {
        WriteToLog(L"Fenêtre en train de se fermer.");
        BOOL windowDestroyed = DestroyWindow(hwnd);
        if (windowDestroyed) {
            WriteToLog(L"\tFenêtre enfant correctement détruite");
        } else {
            WriteToLog(L"\tFenêtre enfant non détruite");
        }
        break;
    }
    Puis l'on passe dans le code lors de la r�ception du message de destruction de la fen�tre 'WM_DESTROY' :

    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
    case WM_DESTROY:
    {
        WriteToLog(L"Je suis dans Destroy de la fenêtre fille");
     
        // Supprimer l'icône de la zone de notification
        Shell_NotifyIcon(NIM_DELETE, &g_nid);
     
        // Détruire et libérer la fenêtre parente wallpaper_hwnd si elle existe
        HWND wallpaper_hwnd = GetParent(hwnd);
        if (wallpaper_hwnd != NULL)
        {
            WriteToLog(L"J'ai trouvé une fenêtre parente, je cherche à la détruire");
            BOOL wallPaperDestroyed = DestroyWindow(wallpaper_hwnd);
            if (wallPaperDestroyed) {
                WriteToLog(L"\tFenêtre parente correctement détruite");
            } else {
                WriteToLog(L"\tFenêtre parente non détruite");
            }
        }
     
        // Changer la couleur de fond de la fenêtre
        HBRUSH hbrBackground = CreateSolidBrush(RGB(255, 0, 0)); // Rouge
        SetClassLongPtr(hwnd, GCLP_HBRBACKGROUND, (LONG_PTR)hbrBackground);
     
        // Forcer le rafraichissement de la fenêtre enfant
        InvalidateRect(hwnd, NULL, TRUE);
     
        // Forcer le rafraichissement de la fenêtre parent
        InvalidateRect(wallpaper_hwnd, NULL, TRUE);
     
        PostQuitMessage(0);
        break;
    }
    Et c'est l� que le bas blesse.
    Le retour dans le terminal m'indique que mon application c'est quitt�e normalement, mais je vois toujours un carr� blanc d�gueulasse entre mon fond d'�cran et les ic�nes du bureau.
    Les retours dans le fichier de log m'indiquent :

    • Que 'Fen�tre parente non d�truite'. Je m'y attendais, c'est 'ProgMan' qui la cr�� je ne dois pas pouvoir la d�truire comme �a.
    • Que 'Fen�tre enfant correctement d�truite'.

    La tentative de changement de couleur du fond de la fen�tre enfant dans 'WM_DESTROY' �choue, alors qu'il fonctionne avant la r�ception du message de fermeture de la fen�tre 'WM_CLOSE'.
    Est-ce l� une preuve suppl�mentaire que ma fen�tre fille est bien d�truite ?

    Est-ce un probl�me de rafraichissement de la fen�tre parent ?
    Une piste pour me permettre de me retrouver avec un espace tout propre et tout vide entre mon arri�re plan de bureau et mes ic�nes ?

    Merci d'avance 😙

  2. #2
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 476
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 476
    Par d�faut
    Je comprends pas trop la logique de votre programme.

    Vous cr�ez une fen�tre selon un proc�d� (SendMessage vers un autre "applicatif"), alors pourquoi tent� de la d�truire via un "DestroyWindow" bien sale ?
    Espionnez encore un peu, via Spy++, pour voir comment l'application de changement de fond d'�cran fait le taf et faites pareil.

    Est-ce l� une preuve suppl�mentaire que ma fen�tre fille est bien d�truite ?
    Pas forc�ment, mais comme vous testez la valeur de retour de "DestroyWindow" ligne 4 du code "case WM_CLOSE:", pourquoi en douter ?
    Testez syst�matiquement les valeurs de retour et utiliser GetLastError pour avoir des explications aux �ventuelles probl�mes (quitte � utiliser des MACRO type SUCCEEDED)

    Avec 1 ou 2 copies d'�cran, �a serait plus explicite pour nous.

  3. #3
    Membre confirm�
    Profil pro
    Inscrit en
    F�vrier 2005
    Messages
    208
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 208
    Par d�faut
    Bonjour bacelar et merci pour cette r�ponse,

    Citation Envoy� par bacelar Voir le message
    Espionnez encore un peu, via Spy++, pour voir comment l'application de changement de fond d'�cran fait le taf et faites pareil...
    Il semblerait que Spy++ ne soit pas pris en compte par Visual Studio Code.

    Citation Envoy� par bacelar Voir le message
    pourquoi tent� de la d�truire via un "DestroyWindow" bien sale ?
    Tout est dit : c'est une tentative bien sale, non fonctionnelle, pour r�soudre mon probl�me.
    �a ne co�tait pas bien cher de tenter.

    Apr�s avoir relu attentivement le tuto originel post� plus haut, j'ai remarqu� ceci :

    Note: Everything you draw onto this layer will stay there until you paint over it, invalidate it, or reset your wallpaper.
    J'ai donc r�cup�r� le chemin vers l'image utilis� comme arri�re plan en d�but de mon application gr�ce � :

    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    WCHAR wallpaperPath[MAX_PATH];
    SystemParametersInfo(SPI_GETDESKWALLPAPER, MAX_PATH, wallpaperPath, 0);
    Et je remets cette image en tant que fond d'�cran avant de quitter l'application :

    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    SystemParametersInfo(SPI_SETDESKWALLPAPER, 0, wallpaperPath, SPIF_UPDATEINIFILE | SPIF_SENDCHANGE);
    Je ne sais pas si c'est le plus propre, mais �a fonctionne 🤷
    J'ai tent� de rafraichir la fen�tre parente gr�ce � InvalidateRect et UpdateWindow apr�s la destruction de la fen�tre fille, sans succ�s.

  4. #4
    Expert confirm�
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 764
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rh�ne (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 764
    Par d�faut
    Citation Envoy� par themoye Voir le message
    J'ai tent� de rafraichir la fen�tre parente gr�ce � InvalidateRect et UpdateWindow apr�s la destruction de la fen�tre fille, sans succ�s.
    Apr�s on parle d'1 API qui a 30 ans (1992) et qui a �t� supplant�e/ surcouch�e plusieurs fois (MFC > WTL > WinForms > WPF, UWP) et donc il y a eu beaucoup de changements

    Mais il me semble que c'est normal ces 2 fonctions ne doivent pas �tre appel�es directement (elles sont appel�s en interne) et il me semble (et en lisant la documentation), il faut envoyer 1 message WM_PAINT.
    Apr�s si tu veux forcer (en regardant vite fait sur Internet), il faut utiliser la fonction RedrawWindow (<- lien vers MSDN)


    �dit: on m'a mis -1 alors que personne ne peut expliquer pourquoi InvalidateRect et UpdateWindow ne fonctionnent pas.

  5. #5
    Membre confirm�
    Profil pro
    Inscrit en
    F�vrier 2005
    Messages
    208
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 208
    Par d�faut
    Hello foetus !

    Citation Envoy� par foetus Voir le message
    Ces 2 fonctions ne doivent pas �tre appel�es directement (elles sont appel�s en interne) et il me semble (et en lisant la documentation), il faut envoyer 1 message WM_PAINT.
    Ce n'est pas l'inverse ? 🤔
    Si je fais le test sur une fen�tre que j'ai cr��, un appel � 'UpdateWindow' envoi le message 'WM_PAINT'.
    De la m�me mani�re qu'un appel � 'DestroyWindow' envoi le message 'WM_DESTROY' etc

  6. #6
    Expert confirm�
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 764
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rh�ne (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 764
    Par d�faut
    Citation Envoy� par themoye Voir le message
    Ce n'est pas l'inverse ? 🤔
    Voici 1 commentaire sur stackoverflow qui reprend la documentation
    InvalidateRect() merely marks a window for repainting. The window is not actually repainted by the OS until the parent thread's message queue, or an explicit call to UpdateWindow() or RedrawWindow(), generates a new WM_PAINT to paint the window. At which time, anything that was on the window gets erased and redrawn. This is basic Win32 GDI stuff
    Donc voila, le fonctionnement est assez simple. Mais il y a 1 histoire de file de messages qui fait que ta fen�tre ignore "tes messages" tant qu'on ne lui pas dit de les traiter (en l'occurrence r�ception d'1 message WM_PAINT)


    �dit: Apr�s il y a peut-�tre d'autres messages que WM_PAINT, comme WM_ERASEBKGND.
    Et ensuite, c'est peut-�tre 1 ""param�trage"" du clipping fen�tre fille/ fen�tre m�re J'ai vu cela sur stackoverflow:
    You can prevent redraw of child windows by setting WS_CLIPCHILDREN to parent window, or by invalidating redraw with the use of RedrawWindow function with RDW_NOCHILDREN flag

  7. #7
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 476
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 476
    Par d�faut
    Il semblerait que Spy++ ne soit pas pris en compte par Visual Studio Code.
    Visual Studio Code, c'est, au d�part une version tr�s light de Visual Studio.
    Visual Studio est gratuit pour les hobbyistes, les petites structures et les projets OpenSource.

    Donc, � moins d'avoir des probl�mes sur la quantit� de donn�es � t�l�charger et � stocker sur les HD, installer Visual Studio n'a pas trop d'inconv�nients.
    R�cup�rer un Spy++ isol� n'est pas impossible, mais � quoi bon ? (� part les dizaines de Giga du pestio : VS, parce que Spy++, �a doit faire dans les quelques dizaines ou centaines de ko)

    �a ne co�tait pas bien cher de tenter.
    Comme de t�l�charger Visual Studio.

    Je ne sais pas si c'est le plus propre, mais �a fonctionne 🤷
    Je trouve m�me votre solution assez �l�gante.
    Mais un petit espionnage pour voir comment les cocos de M$ ont impl�ment� la chose, via Spy++, permettrait de voir s'il y a des cas qu'on n'a pas pris en compte.

    J'ai tent� de rafraichir la fen�tre parente gr�ce � InvalidateRect et UpdateWindow apr�s la destruction de la fen�tre fille, sans succ�s.
    On est clairement pas dans le cas "standard" de ce type d'API, car ces fen�tres n'ont pas �t� cr��es par le thread qui utilise l'API.
    Les valeurs de retour devrait indiquer ce "petit" probl�me.
    Mantra n�1 d'un utilisateur d'une API C : "TOUJOURS v�rifier les valeurs de retour, TOUJOURS".

    M�me si les valeurs de retours "sont bonnes", il faut bien voir que la gestion de l'affichage est asynchrone et que seul le thread cr�ateur de la fen�tre a, par d�faut, un acc�s "directe" avec les structures de la fen�tre (via les API Kernel).
    S'il y a un dialogue avec le processus "Progman" � suivre, Spy++ sera ton ami.

    Apr�s on parle d'1 API qui a 30 ans (1992) et qui a �t� supplant�e/ surcouch�e plusieurs fois (MFC > WTL > WinForms > WPF, UWP) et donc il y a eu beaucoup de changements
    @foetus, heu, je crois que tu t'es gour�.
    1992, c'est la sortie de la technologie NT, et ces API C des enfers, elles existaient bien avant ; en tout cas on les avait d�j� sous Win3.
    Et ces API n'ont pas �t� "supplant�es" depuis, elles ont bien �t� "carross�es" avec des trucs bien plus ergonomiques, je te l'accorde.
    Mais la seul API que support le sous-syst�me "window" de Windows, c'est Win32, donc ces "cochonneries" � base de "InvalidateRect et UpdateWindow".
    Et l�, clairement, le cas d'utilisation de @themoye explose les principes de conceptions des librairies graphiques que tu cites ; aucune n'a �t� pens�e pour dialoguer avec un autre programme "propri�taire" d'une fen�tre.
    Pour ce genre d�acrobaties visuelles, il faut plut�t regarder du c�t� des antiques DDE et autres COM/ActiveX.
    Mais c'est toujours des surcouches � Win16/Win32 et Spy++ ne permet d'espionner qu'� ce niveau "bas" : "Win16/Win32".

    Mais tes remarques, @foetus, sur les peaux de bananes que cachent ces API sont tr�s pertinentes.

    Mais il me semble que c'est normal ces 2 fonctions ne doivent pas �tre appel�es directement (elles sont appel�s en interne)
    Interne � quoi ?
    Oui, si on utilise les APIs/librairies graphiques que tu as mentionn�, c'est � elles, normalement de se d�merder avec tous ces bidules.
    Mais quand on fait de l'API "bas niveau", c'est au programmeur de faire "correctement" tourner le machin, "InvalidateRect et UpdateWindow" compris.

    Mais je le r�p�te, je trouve la solution de @themoye particuli�rement simple et �l�gante. A moins d'effet de bord non pr�vues, je pense qu'elle fait tr�s bien le taf.

    Ce n'est pas l'inverse ? 🤔
    Oul�, vous �tes pr�t pour un voyage sous Doliprane ?
    WM_PAINT, c'est un message "bouchon", qui n'est lu que si c'est le seul et dernier de la file (c'est un esp�ce de bouchon � la surface de la file de message, qu'on �coperait pas le fond de la colonne).
    Faire un "UpdateWindow" sur une fen�tre cr��e par le thread appelant l'API fait appara�tre un WM_PAINT dans la file du thread, oui, mais dans le cas o� la fen�tre n'a pas �t� cr��e par le thread, je suis nettement plus dubitatif.
    Si c'est bien le thread cr�ateur de la fen�tre (donc dans le processus "Progman") qui re�oit le WM_PAINT, encore faut-il qu'il pompe et qu'il atteigne la fin de la file de message pour qu'il le traite "correctement" (gestion de fen�tre filles, etc...).

    De la m�me mani�re qu'un appel � 'DestroyWindow' envoi le message 'WM_DESTROY' etc
    M�me si WM_DESTROY n'est pas un message "bouchon", je ne suis pas s�r que l�encha�nement soit si simple dans le cas d'un thread demandant non cr�ateur de la susdite fen�tre.

    �dit: Apr�s il y a peut-�tre d'autres messages que WM_PAINT, comme WM_ERASEBKGND.
    Si, bien s�r, et bien d'autres, d'o� mon insistance sur le fait de faire une petite session d'espionnage avec Spy++.

    Ici, on est largement en dehors du p�rim�tre habituel de ces API et donc l'utilisation d'autres appels pour compenser des effets de bord est assez probable.

  8. #8
    Expert confirm�
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 764
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rh�ne (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 764
    Par d�faut
    Citation Envoy� par bacelar Voir le message
    Interne � quoi ?
    Ma derni�re exp�rience (2014-2017), c'�tait avec la VCL (Embarcadero Xe 10), autre surcouche objet C++/ Delphi.
    Donc pas forc�ment pr�cis

    Mais ce que je voulais dire c'est que la WinApi impose 1 ""cadre"" pour surcharger tel message, telle action.
    L'exemple typique c'est le BeginPaint/ EndPaint qu'on doit utiliser dans la surcharge du message WM_PAINT

    Donc voil�, la documentation est exhaustive mais ne dit pas le o� le dev doit appeler les fonctions. Par exemple:
    *) SendMessage, PostMessage et RedrawWindow n'ont pas vocation � �tre appel�es dans 1 surcharge de message
    *) � contrario InvalidateRect, UpdateRect, BeginPaint/ EndPaint ont vocation d'�tre en *interne* dans la surcharge des messages ou autres, et des fois des messages pr�cis (comme le WM_PAINT)

    Et c'est pour cela qu'il faut te farder des bouquins sur les arcanes de la WinApi pour comprendre les ""diagramme s�quences""
    Avec la VCL je m'�tais pench� sur la gestion clavier

    Donc voil� je me m�fie, mais je n'ai pas vu sur Internet que InvalidateRect doit �tre obligatoirement utiliser dans la surcharge du message WM_PAINT


    Citation Envoy� par bacelar Voir le message
    1992, c'est la sortie de la technologie NT
    Je n'ai pas �t� pr�cis sur la date (et je n'avais pas v�rifi�) mais pour le d�veloppeur c'est la diff�rence entre le pal�othique et la pr�histoire
    Et en lisant ta r�ponse, dans la WinApi il manque : les threads, l'Unicode (USC-2 � l'�poque si je dis pas de b�tises)

  9. #9
    CGi
    CGi est d�connect�
    Expert confirm�
    Avatar de CGi
    Profil pro
    Inscrit en
    Mars 2002
    Messages
    1 061
    D�tails du profil
    Informations personnelles :
    Localisation : France, Allier (Auvergne)

    Informations forums :
    Inscription : Mars 2002
    Messages : 1 061
    Par d�faut
    Sans entrer dans les d�tails, InvalidateRect est probablement une des fonctions les plus utilis�e pour demander de redessiner une zone client (ou partie d'une zone client) d'une fen�tre. Elle rend invalide la zone, quand une zone est invalide, le systeme va poster un message WM_PAINT dans la file d'attente. Donc mettre cette fonction dans le traitement d'un message WM_PAINT provoquerait une boucle sans fin.
    Site : http://chgi.developpez.com

    Pourquoi faire simple quand on peut faire compliqu� ? (Jacques Rouxel)

  10. #10
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 476
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 476
    Par d�faut
    c'est la diff�rence entre le pal�othique et la pr�histoire
    Ayant connu DOS, je suis bien un tric�ratops du Cr�tac� de l'informatique.

    Et en lisant ta r�ponse, dans la WinApi il manque : les threads, l'Unicode (USC-2 � l'�poque si je dis pas de b�tises)
    On parle de quelle WinApi ?
    Win16, elle n'a pas de thread car on est dans un conteste multit�che "coop�ratif" et non pr�emptif, donc on utilise des "fibres" et pas des threads.
    Pour Win32, c'est la faite � la saucisse des versions et les threads font leur apparition dans la premi�re version (WinNT3.5 ou Win95).
    Pour USC-2, �a n'existait pas (=>MBSM), c'est compliqu� pour des raisons de r�trocompatibilit�.

    @CGi, tout � fait !!!

  11. #11
    Membre confirm�
    Profil pro
    Inscrit en
    F�vrier 2005
    Messages
    208
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 208
    Par d�faut
    Par Saint Sylvain Durif, je n'ai pas vu toutes ces nouvelles r�ponses 😱😱
    On ne re�oit plus de mail lorsque le sujet est pass� en R�solu ?

    Un grand merci � vous, bacelar et foetus pour vos explications suppl�mentaires !

    Comme de t�l�charger Visual Studio.
    J'ai craqu�, j'ai depuis install� Visual Studio.
    Oblig�, il semblerait qu'on ne puisse pas utiliser WebView2 dans VS Code.

  12. #12
    Expert �minent
    Avatar de M�dinoc
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 41
    Localisation : France

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : High Tech - �diteur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par d�faut
    Citation Envoy� par CGi Voir le message
    Sans entrer dans les d�tails, InvalidateRect est probablement une des fonctions les plus utilis�e pour demander de redessiner une zone client (ou partie d'une zone client) d'une fen�tre. Elle rend invalide la zone, quand une zone est invalide, le systeme va poster un message WM_PAINT dans la file d'attente. Donc mettre cette fonction dans le traitement d'un message WM_PAINT provoquerait une boucle sans fin.
    Une boucle sans fin, mais qui a la d�cence de rendre le processeur entre chaque it�ration (et s'interrompre si la fen�tre est r�duite).
    Cela peut �tre utile dans certains cas o� l'on veut un affichage mis � jour "aussi souvent que possible" mais en temps normal on n'a pas besoin de �a et/ou on peut trouver de meilleures fa�ons de le faire.
    (et en plus, cela bloque aussi les messages WM_TIMER qui sont encore plus "bouchon" que WM_PAINT)
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parl� avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

+ R�pondre � la discussion
Cette discussion est r�solue.

Discussions similaires

  1. Probl�me de rafraichissement de ma fen�tre
    Par kafiristanica dans le forum AWT/Swing
    R�ponses: 2
    Dernier message: 13/05/2012, 16h17
  2. Fen�tre noire, probl�me de rafraichissement.
    Par Froyok dans le forum Ogre
    R�ponses: 6
    Dernier message: 12/10/2009, 20h26
  3. R�ponses: 16
    Dernier message: 18/03/2007, 13h30
  4. [JTree]probl�me de rafraichissement
    Par peppena dans le forum Composants
    R�ponses: 9
    Dernier message: 20/01/2004, 14h06
  5. Toujours un probl�me de rafraichissement de DBGrid
    Par tripper.dim dans le forum C++Builder
    R�ponses: 4
    Dernier message: 09/12/2002, 13h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo