de plus ce header contient un bouton que je veux dessiner moi-même et sur
lequel au survol je veux changer le curseur en main.
Pour contrôler le dessin et le curseur je sous-classe le process du header
par le setwindowlong ci-dessous:
je ne décris pas le WM_DRAWITEM qui marche parfaitement, par contre
concernant la transformation du curseur en main, j'ai testé plusieurs
combinaisons:
la procédure de sous-classement ci-dessous fonctionne, mais si j'enlève le
CallWindowProc qui est dans le "if" et que je sors directement sur le return
true ça marche toujours, il doit bien n'y avoir qu'une des 2 solutions qui
est correcte.
A noter que si je rajoute un else avec un CallWindowProc suivi d'un return
false ça marche encore.
LRESULT CALLBACK newprocessaddress(HWND hwndlocal, UINT uMsg, WPARAM wParam,
LPARAM lParam)
{
switch(uMsg)
{
case WM_SETCURSOR: // procédure utilisée pour changer le curseur en
main
if(GetWindowLong((HWND) wParam, GWL_ID)==ID_quit)
{
SetCursor(main);
CallWindowProc(oldprocessaddress, hwndlocal, uMsg, wParam,
lParam);
return true;
} // else éventuel avec CallWindowProc + return false
}
return CallWindowProc(oldprocessaddress, hwndlocal, uMsg, wParam, lParam);
}
Aurais-tu une idée SVP de ce qu'il est correct d'écrire dans ce cas ?
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian ASTOR
Roger a écrit :
la procédure de sous-classement ci-dessous fonctionne, mais si j'enlève le CallWindowProc qui est dans le "if" et que je sors directement sur le return true ça marche toujours, il doit bien n'y avoir qu'une des 2 solutions qui est correcte.
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR, ils font juste return true; après le SetCursor()
Roger a écrit :
la procédure de sous-classement ci-dessous fonctionne, mais si j'enlève le
CallWindowProc qui est dans le "if" et que je sors directement sur le return
true ça marche toujours, il doit bien n'y avoir qu'une des 2 solutions qui
est correcte.
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR,
ils font juste
return true;
après le SetCursor()
la procédure de sous-classement ci-dessous fonctionne, mais si j'enlève le CallWindowProc qui est dans le "if" et que je sors directement sur le return true ça marche toujours, il doit bien n'y avoir qu'une des 2 solutions qui est correcte.
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR, ils font juste return true; après le SetCursor()
Roger
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR, ils font juste return true; après le SetCursor()
Encore merci ! Pas de commentaire sur un éventuel else dans le cas où on ne survole plus... je suppose donc que le break qui renvoie en fait sur la sortie du case WM_SETCURSOR c'est à dire sur le return CallWindowProc(oldprocessaddress, hwndlocal, uMsg, wParam, lParam); est correct (inutile de faire un CallWindowProc suivi d'un return false).
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR,
ils font juste
return true;
après le SetCursor()
Encore merci ! Pas de commentaire sur un éventuel else dans le cas où on ne
survole plus... je suppose donc que le break qui renvoie en fait sur la
sortie du case WM_SETCURSOR c'est à dire sur le return
CallWindowProc(oldprocessaddress, hwndlocal, uMsg, wParam, lParam); est
correct (inutile de faire un CallWindowProc suivi d'un return false).
Dans des exemples de MS où ils sous-classent pour gérer le WM_SETCURSOR, ils font juste return true; après le SetCursor()
Encore merci ! Pas de commentaire sur un éventuel else dans le cas où on ne survole plus... je suppose donc que le break qui renvoie en fait sur la sortie du case WM_SETCURSOR c'est à dire sur le return CallWindowProc(oldprocessaddress, hwndlocal, uMsg, wParam, lParam); est correct (inutile de faire un CallWindowProc suivi d'un return false).