Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer
WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir
( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient
pas.
_comment acceder directement a la memoire virtuelle alloué au processus de
mon prog ?
_Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
et eventuellement, si un puriste avait trouvé la solution pour faire du vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe. En tirer
son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont
pas constitué de la meme facon que les fonctions C: pointeur "this" peut
etre ?)
Ce probleme est récurant lorsque l'on se lance dans la programmation
windows.
DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament
de ces callback.
Votre avis ?
Cordialement
Heinquoi
Mon avis c'est que tu devrais essayer d'expliquer un petit peu plus quels sont tes divers problèmes.
Il semble que tu n'arrives pas à trouver la raison d'une bug dans un de tes programmes, mais j'ai bien peur que faire joujou avec la mémoire virtuelle de ton process ne te soit pas d'un grand secours. Il faudrait décrire un peu ce que tu fais, et tes soucis.
Par ailleurs, j'ai un petit peu de mal à saisir le problème qu'il y aurait entre <windows.h> et C++ Que veux-tu faire ?
-- Pour netscape, il est fournit avec le bouquin : regarde à la fin du livre, y a une disquette 5'1/4. On la voit pas au début parce qu'ils l'ont plié en deux pour qu'elle tienne dans le bouquin. Tu y trouveras l'install de Netscape 2.02 pour windows XP et le JDK 1.0_3b. --benou
heinquoi a écrit :
Votre avis ?
Mon avis c'est que tu devrais essayer d'expliquer un
petit peu plus quels sont tes divers problèmes.
Il semble que tu n'arrives pas à trouver la raison d'une
bug dans un de tes programmes, mais j'ai bien peur que
faire joujou avec la mémoire virtuelle de ton process
ne te soit pas d'un grand secours. Il faudrait décrire
un peu ce que tu fais, et tes soucis.
Par ailleurs, j'ai un petit peu de mal à saisir le
problème qu'il y aurait entre <windows.h> et C++
Que veux-tu faire ?
--
Pour netscape, il est fournit avec le bouquin : regarde à la fin du
livre, y a une disquette 5'1/4. On la voit pas au début parce qu'ils
l'ont plié en deux pour qu'elle tienne dans le bouquin. Tu y trouveras
l'install de Netscape 2.02 pour windows XP et le JDK 1.0_3b.
--benou
Mon avis c'est que tu devrais essayer d'expliquer un petit peu plus quels sont tes divers problèmes.
Il semble que tu n'arrives pas à trouver la raison d'une bug dans un de tes programmes, mais j'ai bien peur que faire joujou avec la mémoire virtuelle de ton process ne te soit pas d'un grand secours. Il faudrait décrire un peu ce que tu fais, et tes soucis.
Par ailleurs, j'ai un petit peu de mal à saisir le problème qu'il y aurait entre <windows.h> et C++ Que veux-tu faire ?
-- Pour netscape, il est fournit avec le bouquin : regarde à la fin du livre, y a une disquette 5'1/4. On la voit pas au début parce qu'ils l'ont plié en deux pour qu'elle tienne dans le bouquin. Tu y trouveras l'install de Netscape 2.02 pour windows XP et le JDK 1.0_3b. --benou
Ambassadeur Kosh
> et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe.
ça s'apelle les MFC.
En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment
NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
confusion.
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament de ces callback. Votre avis ?
à mon avi tu essayes de nous dire que l'environement que tu utilises n'est pas un framework objet. ça, on est bien au courant. et ça fait chier pas mal de monde d'écrire de la merde (le cycle inferanal arf arf arf) donc, hosanna et gloire à .Net. pour les callback, je crois comprendre ton souci : une solution, c'est d'utiliser les Event, ou alors le systeme de messagerie MFC.
Cordialement Heinquoi
A+
> et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe.
ça s'apelle les MFC.
En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment
NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont
pas constitué de la meme facon que les fonctions C: pointeur "this" peut
etre ?)
confusion.
Ce probleme est récurant lorsque l'on se lance dans la programmation
windows. DirectX par exemple ou APIWindows ne sont pas adapté au
C++ a cause notament de ces callback.
Votre avis ?
à mon avi tu essayes de nous dire que l'environement que tu utilises n'est
pas un framework objet. ça, on est bien au courant. et ça fait chier pas mal
de monde d'écrire de la merde (le cycle inferanal arf arf arf) donc, hosanna
et gloire à .Net. pour les callback, je crois comprendre ton souci : une
solution, c'est d'utiliser les Event, ou alors le systeme de messagerie MFC.
> et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe.
ça s'apelle les MFC.
En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment
NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
confusion.
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament de ces callback. Votre avis ?
à mon avi tu essayes de nous dire que l'environement que tu utilises n'est pas un framework objet. ça, on est bien au courant. et ça fait chier pas mal de monde d'écrire de la merde (le cycle inferanal arf arf arf) donc, hosanna et gloire à .Net. pour les callback, je crois comprendre ton souci : une solution, c'est d'utiliser les Event, ou alors le systeme de messagerie MFC.
Cordialement Heinquoi
A+
Patrick Philippot
heinquoi wrote:
_comment acceder directement a la memoire virtuelle alloué au processus de mon prog ? _Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
On ne fait pas ça dans un programme Windows. Surtout pour manipuler une adresse. Oubliez.
et eventuellement, si un puriste avait trouvé la solution pour faire du vrai C++ avec <Windows.h> et notament placer WndProc dans une classe.
Problème connu et sans solution vraiment satisfaisante.
Une fonction callback non static ne peut pas être une fonction membre d'une classe C++. En effet, toute méthode non static C++ prend en premier paramètre caché le fameux this qui est absolument ignoré par l'appelant de la callback. Impossible donc pour cause d'erreur de dépilement systématique.
Par contre, si la fonction membre est static, elle peut-être une callback. Mais en tant que fonction static, elle n'a pas accès aux données d'instance (pas de this). Ce qui est rédhibitoire dans de nombreux cas. La seule solution est alors de maintenir un pointeur global sur l'instance courante. Supposons que la classe soit CMaClasse, on déclare un pointeur global
CMaClasse* g_pInstance;
On renseigne ce pointeur avec une instance valide avant de déclencher les opérations qui vont provoquer l'appel de la callback et dans le corps de la callback, on utilise ce pointeur pour accéder aux données d'instance (g_pInstance->m_maDonnee). C'est le seul moyen.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
heinquoi wrote:
_comment acceder directement a la memoire virtuelle alloué au
processus de mon prog ?
_Et/ou acceder directement à la memoire virtuelle general ? ( genre
dump)
On ne fait pas ça dans un programme Windows. Surtout pour manipuler une
adresse. Oubliez.
et eventuellement, si un puriste avait trouvé la solution pour faire
du vrai C++ avec <Windows.h> et notament placer WndProc dans une
classe.
Problème connu et sans solution vraiment satisfaisante.
Une fonction callback non static ne peut pas être une fonction membre
d'une classe C++. En effet, toute méthode non static C++ prend en
premier paramètre caché le fameux this qui est absolument ignoré par
l'appelant de la callback. Impossible donc pour cause d'erreur de
dépilement systématique.
Par contre, si la fonction membre est static, elle peut-être une
callback. Mais en tant que fonction static, elle n'a pas accès aux
données d'instance (pas de this). Ce qui est rédhibitoire dans de
nombreux cas. La seule solution est alors de maintenir un pointeur
global sur l'instance courante. Supposons que la classe soit CMaClasse,
on déclare un pointeur global
CMaClasse* g_pInstance;
On renseigne ce pointeur avec une instance valide avant de déclencher
les opérations qui vont provoquer l'appel de la callback et dans le
corps de la callback, on utilise ce pointeur pour accéder aux données
d'instance (g_pInstance->m_maDonnee). C'est le seul moyen.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
_comment acceder directement a la memoire virtuelle alloué au processus de mon prog ? _Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
On ne fait pas ça dans un programme Windows. Surtout pour manipuler une adresse. Oubliez.
et eventuellement, si un puriste avait trouvé la solution pour faire du vrai C++ avec <Windows.h> et notament placer WndProc dans une classe.
Problème connu et sans solution vraiment satisfaisante.
Une fonction callback non static ne peut pas être une fonction membre d'une classe C++. En effet, toute méthode non static C++ prend en premier paramètre caché le fameux this qui est absolument ignoré par l'appelant de la callback. Impossible donc pour cause d'erreur de dépilement systématique.
Par contre, si la fonction membre est static, elle peut-être une callback. Mais en tant que fonction static, elle n'a pas accès aux données d'instance (pas de this). Ce qui est rédhibitoire dans de nombreux cas. La seule solution est alors de maintenir un pointeur global sur l'instance courante. Supposons que la classe soit CMaClasse, on déclare un pointeur global
CMaClasse* g_pInstance;
On renseigne ce pointeur avec une instance valide avant de déclencher les opérations qui vont provoquer l'appel de la callback et dans le corps de la callback, on utilise ce pointeur pour accéder aux données d'instance (g_pInstance->m_maDonnee). C'est le seul moyen.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Manuel Leclerc
Patrick Philippot a écrit :
CMaClasse* g_pInstance;
On renseigne ce pointeur avec une instance valide avant de déclencher les opérations qui vont provoquer l'appel de la callback et dans le corps de la callback, on utilise ce pointeur pour accéder aux données d'instance (g_pInstance->m_maDonnee). C'est le seul moyen.
Berk ! Et si la callback peut provoque un nouvel appel pour une autre instance, il faut gérer une pile ?
Une solution, ça serait pas de stocker le CMaClasse* dans les windows words et de coder une windowproc qui fait un appel systématique à une windowproc d'instance ?
-- <Mooby> la résolution de l'année 202 <Mooby> * plus de fautes de frappes
Patrick Philippot a écrit :
CMaClasse* g_pInstance;
On renseigne ce pointeur avec une instance valide avant
de déclencher les opérations qui vont provoquer l'appel
de la callback et dans le corps de la callback, on utilise
ce pointeur pour accéder aux données d'instance
(g_pInstance->m_maDonnee). C'est le seul moyen.
Berk ! Et si la callback peut provoque un nouvel appel
pour une autre instance, il faut gérer une pile ?
Une solution, ça serait pas de stocker le CMaClasse*
dans les windows words et de coder une windowproc qui
fait un appel systématique à une windowproc d'instance ?
--
<Mooby> la résolution de l'année 202
<Mooby> * plus de fautes de frappes
On renseigne ce pointeur avec une instance valide avant de déclencher les opérations qui vont provoquer l'appel de la callback et dans le corps de la callback, on utilise ce pointeur pour accéder aux données d'instance (g_pInstance->m_maDonnee). C'est le seul moyen.
Berk ! Et si la callback peut provoque un nouvel appel pour une autre instance, il faut gérer une pile ?
Une solution, ça serait pas de stocker le CMaClasse* dans les windows words et de coder une windowproc qui fait un appel systématique à une windowproc d'instance ?
-- <Mooby> la résolution de l'année 202 <Mooby> * plus de fautes de frappes
Manuel Leclerc
Ambassadeur Kosh a écrit :
pour les callback, je crois comprendre ton souci : une solution, c'est d'utiliser les Event, ou alors le systeme de messagerie MFC.
Ou alors les mutex, les pipes, la mémoire partagée. Ou Sleep.
-- Hey Mister D.J. Put a record on I wanna dance with my baby
Ambassadeur Kosh a écrit :
pour les callback, je crois comprendre ton souci : une
solution, c'est d'utiliser les Event, ou alors le systeme
de messagerie MFC.
Ou alors les mutex, les pipes, la mémoire partagée. Ou Sleep.
--
Hey Mister D.J.
Put a record on
I wanna dance with my baby
"Ambassadeur Kosh" a écrit dans le message de news:6ETfc.38394$
> et eventuellement, si un puriste avait trouvé la solution pour faire du vrai > C++ avec <Windows.h> et notament placer WndProc dans une classe.
ça s'apelle les MFC.
ou OWL, VCL, CLX, wxWindows, etc... En bref y'a le choix. Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur 10 pages ?
Arnaud Debaene
heinquoi wrote:
Bjr,
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir ( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient pas. _comment acceder directement a la memoire virtuelle alloué au processus de mon prog ?
Ben... avec un pointeur, mais si tu nous disais exactement ce que tu voudrais faire...
_Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
Pas possible (du moins de manière "officielle" et simple ... je vois déjà AMcD venir avec ses gros sabots de kernel-gourou... ;-) - et surtout complètement inutile.
et eventuellement, si un puriste avait trouvé la solution pour faire du vrai C++ avec <Windows.h> et notament placer WndProc dans une classe.
Le problème principal est que la WndProc est nécessairement une méthode statique, et qu'on ne peut donc pas associer simplement un HWND à une instance de classe "fenetre".
Il y a plusieurs solutions. D'autres en on déjà évoqué certaines : - Les MFC : Il y a une table globale HWND<-->Instance de CWnd pour toute l'application (avec des siouxeries impossibles pour pouvoir gérer les DLLs...). Le défgaut bien sûr, c'est que plus tu as de fenêtres, plus ca prend du temps de parcourir cette table pour trouver la bonne instance.
- Utilisation du champ USERDATA asocié à chaque fenêtre pour y stocker un pointeur. Je ne connais pas de framework qui utilises cela, mais c'est une possibilité (avec pas mal de limitations néanmoins - entre autres que ce champ n'est plus disponible pour autre chose et que les perfs sont assez décevantes).
- Méthode d'ATL (à mon avis la meilleure, mais ca fait appel à pas mal de magie noir / assembleur) : un thunk. Grosso-modo, on sous-classe la fenêtre (SetWindowLong(GWLP_WNDPROC)) en passant comme nouvelle WndProc une petite fonction créée dyanmiquement en assembleur (le thunk), qui modifie la pile d'appel en remplacant le paramètre HWND par le pointeur de l'instance correspondante. Dans ATL, le principe est encore complexifié par le fait que CWindowImpl est une classe lourdement template, mais ca vaut le coup d'oeil! Voir les classes CWindowImpl et CWndProcThunk pour avoir une idée de la bête.
- Sans doute d'autres que je ne connais pas...
En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
Exact - entre autres choses : il y a aussi le fait que dans le cas d'une fonction virtuelle / d'une classe avec héritage multiple, le compilateur a besoin d'embarquer des informations sur le type de l'instance dans le pointeur de fonction membre, ce qui fait qu'un pointeur vers une fonction membre ne fait pas nécessairement 32 bits, il peut faire plus selon les cas.
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament de ces callback. Votre avis ?
Qu'il y a divers frameworks pour gérer çà et qu'il est recommandé de les utiliser, parce qu'implémenter les différentes solutions que j'ai évoqué, c'est un *gros* boulot qu'il vaut mieux éviter de refaire soi même.
Personnellement, si tu veux rester au C++, je recommenderais ATL/WTL ou bien WxWidgets (MFC...beark - déjà la gestion des fenêtre est très moyenne mais en plus tu es obligé de te palucher un tas de trucs en plus dont tu n'as pas forcément besoin). Concernant DirectX.... L'interface de DirectX c'est du COM, donc c'est de l'objet :-)
Arnaud MVP - VC
heinquoi wrote:
Bjr,
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la
citer WndProc, j'ai chercher à acceder directement à la memoire, sans
y parvenir ( sous dos nous avons la fameuse peekb ) mais sous win32
je n'y parvient pas.
_comment acceder directement a la memoire virtuelle alloué au
processus de mon prog ?
Ben... avec un pointeur, mais si tu nous disais exactement ce que tu
voudrais faire...
_Et/ou acceder directement à la memoire virtuelle general ? ( genre
dump)
Pas possible (du moins de manière "officielle" et simple ... je vois déjà
AMcD venir avec ses gros sabots de kernel-gourou... ;-) - et surtout
complètement inutile.
et eventuellement, si un puriste avait trouvé la solution pour faire
du vrai C++ avec <Windows.h> et notament placer WndProc dans une
classe.
Le problème principal est que la WndProc est nécessairement une méthode
statique, et qu'on ne peut donc pas associer simplement un HWND à une
instance de classe "fenetre".
Il y a plusieurs solutions. D'autres en on déjà évoqué certaines :
- Les MFC : Il y a une table globale HWND<-->Instance de CWnd pour toute
l'application (avec des siouxeries impossibles pour pouvoir gérer les
DLLs...). Le défgaut bien sûr, c'est que plus tu as de fenêtres, plus ca
prend du temps de parcourir cette table pour trouver la bonne instance.
- Utilisation du champ USERDATA asocié à chaque fenêtre pour y stocker un
pointeur. Je ne connais pas de framework qui utilises cela, mais c'est une
possibilité (avec pas mal de limitations néanmoins - entre autres que ce
champ n'est plus disponible pour autre chose et que les perfs sont assez
décevantes).
- Méthode d'ATL (à mon avis la meilleure, mais ca fait appel à pas mal de
magie noir / assembleur) : un thunk. Grosso-modo, on sous-classe la fenêtre
(SetWindowLong(GWLP_WNDPROC)) en passant comme nouvelle WndProc une petite
fonction créée dyanmiquement en assembleur (le thunk), qui modifie la pile
d'appel en remplacant le paramètre HWND par le pointeur de l'instance
correspondante. Dans ATL, le principe est encore complexifié par le fait que
CWindowImpl est une classe lourdement template, mais ca vaut le coup d'oeil!
Voir les classes CWindowImpl et CWndProcThunk pour avoir une idée de la
bête.
- Sans doute d'autres que je ne connais pas...
En tirer son adresse sur un pointeur type WNDPROC, la ce
serais vraiment NOEL pour moi. ( j'ai le sentiment que les fonctions
appartenant à un classe ne sont pas constitué de la meme facon que
les fonctions C: pointeur "this" peut etre ?)
Exact - entre autres choses : il y a aussi le fait que dans le cas d'une
fonction virtuelle / d'une classe avec héritage multiple, le compilateur a
besoin d'embarquer des informations sur le type de l'instance dans le
pointeur de fonction membre, ce qui fait qu'un pointeur vers une fonction
membre ne fait pas nécessairement 32 bits, il peut faire plus selon les cas.
Ce probleme est récurant lorsque l'on se lance dans la programmation
windows.
DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause
notament de ces callback.
Votre avis ?
Qu'il y a divers frameworks pour gérer çà et qu'il est recommandé de les
utiliser, parce qu'implémenter les différentes solutions que j'ai évoqué,
c'est un *gros* boulot qu'il vaut mieux éviter de refaire soi même.
Personnellement, si tu veux rester au C++, je recommenderais ATL/WTL ou bien
WxWidgets (MFC...beark - déjà la gestion des fenêtre est très moyenne mais
en plus tu es obligé de te palucher un tas de trucs en plus dont tu n'as pas
forcément besoin).
Concernant DirectX.... L'interface de DirectX c'est du COM, donc c'est de
l'objet :-)
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir ( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient pas. _comment acceder directement a la memoire virtuelle alloué au processus de mon prog ?
Ben... avec un pointeur, mais si tu nous disais exactement ce que tu voudrais faire...
_Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
Pas possible (du moins de manière "officielle" et simple ... je vois déjà AMcD venir avec ses gros sabots de kernel-gourou... ;-) - et surtout complètement inutile.
et eventuellement, si un puriste avait trouvé la solution pour faire du vrai C++ avec <Windows.h> et notament placer WndProc dans une classe.
Le problème principal est que la WndProc est nécessairement une méthode statique, et qu'on ne peut donc pas associer simplement un HWND à une instance de classe "fenetre".
Il y a plusieurs solutions. D'autres en on déjà évoqué certaines : - Les MFC : Il y a une table globale HWND<-->Instance de CWnd pour toute l'application (avec des siouxeries impossibles pour pouvoir gérer les DLLs...). Le défgaut bien sûr, c'est que plus tu as de fenêtres, plus ca prend du temps de parcourir cette table pour trouver la bonne instance.
- Utilisation du champ USERDATA asocié à chaque fenêtre pour y stocker un pointeur. Je ne connais pas de framework qui utilises cela, mais c'est une possibilité (avec pas mal de limitations néanmoins - entre autres que ce champ n'est plus disponible pour autre chose et que les perfs sont assez décevantes).
- Méthode d'ATL (à mon avis la meilleure, mais ca fait appel à pas mal de magie noir / assembleur) : un thunk. Grosso-modo, on sous-classe la fenêtre (SetWindowLong(GWLP_WNDPROC)) en passant comme nouvelle WndProc une petite fonction créée dyanmiquement en assembleur (le thunk), qui modifie la pile d'appel en remplacant le paramètre HWND par le pointeur de l'instance correspondante. Dans ATL, le principe est encore complexifié par le fait que CWindowImpl est une classe lourdement template, mais ca vaut le coup d'oeil! Voir les classes CWindowImpl et CWndProcThunk pour avoir une idée de la bête.
- Sans doute d'autres que je ne connais pas...
En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
Exact - entre autres choses : il y a aussi le fait que dans le cas d'une fonction virtuelle / d'une classe avec héritage multiple, le compilateur a besoin d'embarquer des informations sur le type de l'instance dans le pointeur de fonction membre, ce qui fait qu'un pointeur vers une fonction membre ne fait pas nécessairement 32 bits, il peut faire plus selon les cas.
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament de ces callback. Votre avis ?
Qu'il y a divers frameworks pour gérer çà et qu'il est recommandé de les utiliser, parce qu'implémenter les différentes solutions que j'ai évoqué, c'est un *gros* boulot qu'il vaut mieux éviter de refaire soi même.
Personnellement, si tu veux rester au C++, je recommenderais ATL/WTL ou bien WxWidgets (MFC...beark - déjà la gestion des fenêtre est très moyenne mais en plus tu es obligé de te palucher un tas de trucs en plus dont tu n'as pas forcément besoin). Concernant DirectX.... L'interface de DirectX c'est du COM, donc c'est de l'objet :-)
Arnaud MVP - VC
heinquoi
merci à tous pour leurs réponces. vous m'avez tous données de nouveaux moyens et/ou outils pour avancer cordialement heinquoi
"heinquoi" a écrit dans le message de news:407ffa6f$0$19481$
Bjr,
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir ( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient pas. _comment acceder directement a la memoire virtuelle alloué au processus de mon prog ? _Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe. En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause
notament
de ces callback. Votre avis ? Cordialement Heinquoi
merci à tous pour leurs réponces.
vous m'avez tous données de nouveaux moyens et/ou outils pour avancer
cordialement
heinquoi
"heinquoi" <heinquoi1@libertysurf.fr> a écrit dans le message de
news:407ffa6f$0$19481$636a15ce@news.free.fr...
Bjr,
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer
WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir
( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient
pas.
_comment acceder directement a la memoire virtuelle alloué au processus de
mon prog ?
_Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe. En tirer
son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont
pas constitué de la meme facon que les fonctions C: pointeur "this" peut
etre ?)
Ce probleme est récurant lorsque l'on se lance dans la programmation
windows.
DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause
notament
de ces callback.
Votre avis ?
Cordialement
Heinquoi
merci à tous pour leurs réponces. vous m'avez tous données de nouveaux moyens et/ou outils pour avancer cordialement heinquoi
"heinquoi" a écrit dans le message de news:407ffa6f$0$19481$
Bjr,
Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir ( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient pas. _comment acceder directement a la memoire virtuelle alloué au processus de mon prog ? _Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)
et eventuellement, si un puriste avait trouvé la solution pour faire du
vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe. En tirer son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont pas constitué de la meme facon que les fonctions C: pointeur "this" peut etre ?)
Ce probleme est récurant lorsque l'on se lance dans la programmation windows. DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause
notament
de ces callback. Votre avis ? Cordialement Heinquoi
Ambassadeur Kosh
> ou OWL, VCL, CLX, wxWindows, etc... En bref y'a le choix.
c clair. VCL / CLX, j'aimais bien, mais bon, depuis qu'il y a .Net, c'est difficile d'en decrocher...
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur
10
pages ?
ben oui. comme y'en a qui continuent à faire du printf à fond les manettes, plutot que d'utiliser une classe SpecializedWriter et StringBuilder.
> ou OWL, VCL, CLX, wxWindows, etc...
En bref y'a le choix.
c clair. VCL / CLX, j'aimais bien, mais bon, depuis qu'il y a .Net, c'est
difficile d'en decrocher...
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur
10
pages ?
ben oui. comme y'en a qui continuent à faire du printf à fond les manettes,
plutot que d'utiliser une classe SpecializedWriter et StringBuilder.
> ou OWL, VCL, CLX, wxWindows, etc... En bref y'a le choix.
c clair. VCL / CLX, j'aimais bien, mais bon, depuis qu'il y a .Net, c'est difficile d'en decrocher...
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur
10
pages ?
ben oui. comme y'en a qui continuent à faire du printf à fond les manettes, plutot que d'utiliser une classe SpecializedWriter et StringBuilder.
AMcD®
Alexandre wrote:
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur 10 pages ?
Oui moi.
Tu n'es pas "obligé" de programmer salement non plus hein. Ce n'est pas le langage, le type de bibliothèque de classes ou l'outil de développement qui font la qualité d'un programme..
-- AMcD®
http://arnold.mcdonald.free.fr/
Alexandre wrote:
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case...
sur 10 pages ?
Oui moi.
Tu n'es pas "obligé" de programmer salement non plus hein. Ce n'est pas le
langage, le type de bibliothèque de classes ou l'outil de développement qui
font la qualité d'un programme..
Y'en a encore qui s'emmerdent avec WndProc et les switch(...) case... sur 10 pages ?
Oui moi.
Tu n'es pas "obligé" de programmer salement non plus hein. Ce n'est pas le langage, le type de bibliothèque de classes ou l'outil de développement qui font la qualité d'un programme..
