Voila, tout est dans le titre;
j’ai du le faire une dizaine de fois mais ,y’a plus moyen de retourver cette fonction…
donc si des ames charitables passent par la et ont quelques secondes a m’accorder , merci d’avance
Copier collé de la doc MFC (CDialog overview) :
Call CWinApp::SetDialogBkColor to set the background color for dialog boxes in your application.
Par contre j’ai pas essayé.
a premiere vu , je suis pas sur de pouvoir utiliser ta fonction sur des CDialog; ou alors c’est que je me suis planté , ce qui est aussi probable; mais merci quand meme.( note pour plutard : installer MSDN… un jour peut etre…)
en fait , la fonction marche mais applique la meme couleur a l’ensemble des Windows de l’appli; mais bon je vais essayé de me demerder avec ca; merci.
Hahaha c’est pas très objet ça
Je viens d’essayer rapidement, et ça marche … tu appele la fonction SetDialogBkColor dans ta classe principale (qui hérite de CWinApp) juste avant de créer une boite de dialogue CDialog, et hop elle prend les couleurs que tu lui donne…
si t’as pas la MSDN :
CWinApp::SetDialogBkColor
void SetDialogBkColor( COLORREF clrCtlBk = RGB(192, 192, 192), COLORREF clrCtlText = RGB(0, 0, 0) );
Parameters
clrCtlBk The dialog background color for the application.
clrCtlText The dialog control color for the application.
Remarks
Call this member function from within the InitInstance member function to set the default background and text color for dialog boxes and message boxes within your application.
Example
BOOL CMyApp::InitInstance()
{
// Standard initialization
SetDialogBkColor(); // Set dialog background color to gray
LoadStdProfileSettings(); // Load standard INI file options (including MRU)
// …
}
Sinon, tu peux tj aller voir sur http://msdn.microsoft.com
Si ce sont toutes les Dialog Box qui sont affectées par la nouvelle couleur c’est normal hein
J’ai jamais essayer de faire ca. Mais bon je vais essayer de t’expliquer pourquoi ca fait ca. Voila, tout fenetre, controle sous windows est attachée à objet WNDLCASS.
Cette structure définit un tas de parametres dont entres autres le fond de la fenetre. Toutes les boites de dialogue utilise le même WNDCLASS, et donc on la meme couleur de fond. Toutefois il est possible d’interfacer l’effacement de la fenetre afin d’empecher windows de mettre sa couleur de fond, et de cette facon personnalisé la couleur de fond de ta fenetre.
Voici un extrait de l’msdn (anglais of course, et il faut bien sur le mettre a la sauce MFC)
[quote]
The WM_ERASEBKGND message is sent when the window background must be erased (for example, when a window is resized). The message is sent to prepare an invalidated portion of a window for painting.
The DefWindowProc function erases the background by using the class background brush specified by the hbrBackground member of the WNDCLASS structure.
If hbrBackground is NULL, the application should process the WM_ERASEBKGND message and erase the background. An application should return nonzero in response to WM_ERASEBKGND if it processes the message and erases the background; this indicates that no further erasing is required.
If the application returns zero, the window will remain marked for erasing. (Typically, this indicates that the fErase member of the PAINTSTRUCT structure will be TRUE.)
Donc en gros il faut intercepter l’évenement WM_ERASEBKGND et renvoyer une valeur non nulle pour dire au systeme de pas effacer la fenetre. Et ensuite faire l’effacement à la main.
Bref … la fete.
Bon courage
Ce message a été édité par Vko le 06/06/2003
Oupss j’ai répondu un peu rapidement tout à l’heure . En fait, tu veux définir une couleur de fond pour UNE boîte de dialog … etc… bah mon colon t’es dans la merde ! oui, aussi curieux que cela puisse paraître, c’est la croix et la banière pour personnaliser une application à base de MFCs. J’ai déjà fait ce genre de truc, eh bien je peux dire que ça m’a carrément gavé. C’est nul ! je ne dis pas que ce n’est pas possible hein, mais c’est du grand portenawak sous les MFCs… ça pue le code non objet par excellence. Ca m’a carrément dégouté des MFCs. Il faut jouer avec les “Device Context” et tout un artifice “qui pue”. Quand on voit comment c’est bien réalisé chez Borland, ça fait frémir.
Pour finir sur une note positive (sinon Glop va se sentir aggro
, les MFCs sont assez simples lorsqu’il s’agit de pondre une appli “standard”. Dès lors que tu veux faire quelque chose d’un peu sioux, je te conseille de fouiller sur le NET pour trouver la classe “qui va bien” développée par un courageux. Par exemple, garder les positions des controls, placés sur une fenêtre, relativement à un bord lorsqu’elle est redimensionnée… eh bien bon courage. tsssss…
Ce message a été édité par Moktar le 06/06/2003
[quote]Par exemple, garder les positions des controls, placés sur une fenêtre, relativement à un bord lorsqu’elle est redimensionnée… eh bien bon courage. tsssss…[/quote]Je crois que tu te rend pas compte de la complexite de faire un truc generique qui marche pour faire ca C’est plusieurs dizaines de milliers de lignes de code managed (en natif je te raconte meme pas) pour faire ca.
Sinon utiliser les messages c’est quand meme super simple. Faire du custom painting quel que soit l’interface c’est pas simple. Enfin router WM_ERASEBACKGROUND et faire new Brush, FillRectangle c’est vraiment pas la mort et ca repond complement au design objet si on considere qu’on route des messages. Je reconnais que c’est pas super evident comme etat d’esprit a choper et c’est pour ca que les winforms (en .net) rajoutent toute une joli couche par dessus tout ca (win32 direct pas MFC bien sur) pour rendre ca plus facile a utiliser.
Ce message a été édité par GloP le 06/06/2003
[quote]
[quote]Par exemple, garder les positions des controls, placés sur une fenêtre, relativement à un bord lorsqu’elle est redimensionnée… eh bien bon courage. tsssss…[/quote]Je crois que tu te rend pas compte de la complexite de faire un truc generique qui marche pour faire ca .
Pour cette histoire de couleur de fond (idem pour le foreground), c’est cul cul que la CWnd ne possède pas des attributs couleurs. Hop, je veux la couleur RGB machin en fond et ça se démerde en natif. Bah oui quoi, comme avec l’OWL. Qu’est-ce que je vais me faire chier à capturer l’événement WM_ERASEBACKGROUND (ou bien WM_PAINT) pour ensuite récupérer les coordonnées du rectangle qui est concerné par le PAINT, pour enfin repeindre avec la couleur d’origine. Toutes ces infos sont connues par la fenêtre dès le début (les coordonnées du rectangle, par exemple, nous sont fournies par elle-même). D’ailleurs, on ne s’occupe de rien pour réafficher le texte d’un bouton lorsque une fenêtre lui passe au-dessus, alors que les mêmes événements sont déroulés. Non, de ce point de vue, ça manque cruellement de service de plus haut niveau.
La messagerie est par contre très bien branlée. Pour ceux qui se sont déjà amusés à espionner les différents messages échangés entre fenêtres et autre composants (voire l’OS ou d’autres applis), c’est vraiment halluscinant leur nombre. Avec Spy++ c’est très facile. On peut même trouver des pistes du meilleur événement à capturer pour faire un certain boulot sur un certain événement, rien qu’avec cet outils d’analyse. Ca c’est puissant comme outil ! Idem pour l’environnement de développement (y compris le debugger). Excellent, j’adore. Le must pour moi (rien à voir avec GDB et une couche DDD => c’est du pipi de chat). Pour aller plus loin, on peut même contrôler une application (process) depuis une autre rien qu’en lui envoyant les messages “qui vont bien” (jusque dans une certaines mesure bien sûr).
La notion événementielle je la connais bien et j’apprécie ce principe. Je trouve ça très élégant et fonctionnel. Il y a quelques années, je ne faisais que ça d’ailleurs et j’ai même eu du mal à redévelopper en C “à plat” (séquentiel) .
Pour finir, il n’y a pas de corélation entre cette notion événementielle (messagerie) et la notion objet. .
Mon XP.