Je me suis mis à wxWindow sous Dev-C++ pour quitter MFC et VC++ 6.0 qui
refuse de compiler mon projet (pb de templates et de STL).
Et la, je suis confronté à un rigolo probleme : De nombreuses fonctions
membres de classes wxXXX qui ont le meme nom dans l'API Windows se voient
renomés a cause de #define liés à l'unicode.
Exemple :
wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de
En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques
Windows dans mon projet, sous peine de voir des fonctions renommées ? Cela
m'ennuie car j'ai l'habitude de fonctionné avec OutputDebugString et
DebugView.exe.
Existe t il une solution a mon probleme, ou bien dois-je desormais me mettre
aux fonctionnalités de trace de wxWindows ?
En esperant que ma question n'est pas "trop" HS sur ce forum.
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
Patrick \Zener\ Brunet
Bonjour.
"Jeremie Fouche" a écrit dans le message de news:cenurr$882$
Bonjour a tous
Je me suis mis à wxWindow sous Dev-C++ pour quitter MFC et VC++ 6.0 qui refuse de compiler mon projet (pb de templates et de STL). Et la, je suis confronté à un rigolo probleme : De nombreuses fonctions membres de classes wxXXX qui ont le meme nom dans l'API Windows se voient renomés a cause de #define liés à l'unicode.
Exemple : wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de
En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques Windows dans mon projet, sous peine de voir des fonctions renommées ? Cela m'ennuie car j'ai l'habitude de fonctionné avec OutputDebugString et DebugView.exe.
Existe t il une solution a mon probleme, ou bien dois-je desormais me
mettre
aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer : - soit placer le header qui subit l'autre au-dessus dans la séquence d'inclusions, - soit s'il en dépend aussi, le laisser en dessous mais faire un #undef UNICODE entre les deux.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif d'être compatible. En fait si le préprocesseur renomme TOUTES les occurences d'un nom de fonction, c'est sans importance, et transparent pour le programmeur. Par contre si vous recompilez partiellement et linkez un mix, vous vous aventurez en terrain miné.
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Hope It Helps,
Cordialement, PZB
Bonjour.
"Jeremie Fouche" <jeremie.fouche.tonmasque@tiscali.fr> a écrit dans le
message de news:cenurr$882$1@news.tiscali.fr...
Bonjour a tous
Je me suis mis à wxWindow sous Dev-C++ pour quitter MFC et VC++ 6.0 qui
refuse de compiler mon projet (pb de templates et de STL).
Et la, je suis confronté à un rigolo probleme : De nombreuses fonctions
membres de classes wxXXX qui ont le meme nom dans l'API Windows se voient
renomés a cause de #define liés à l'unicode.
Exemple :
wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de
En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques
Windows dans mon projet, sous peine de voir des fonctions renommées ? Cela
m'ennuie car j'ai l'habitude de fonctionné avec OutputDebugString et
DebugView.exe.
Existe t il une solution a mon probleme, ou bien dois-je desormais me
mettre
aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer :
- soit placer le header qui subit l'autre au-dessus dans la séquence
d'inclusions,
- soit s'il en dépend aussi, le laisser en dessous mais faire un #undef
UNICODE entre les deux.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif
d'être compatible. En fait si le préprocesseur renomme TOUTES les occurences
d'un nom de fonction, c'est sans importance, et transparent pour le
programmeur. Par contre si vous recompilez partiellement et linkez un mix,
vous vous aventurez en terrain miné.
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être
aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du
type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
"Jeremie Fouche" a écrit dans le message de news:cenurr$882$
Bonjour a tous
Je me suis mis à wxWindow sous Dev-C++ pour quitter MFC et VC++ 6.0 qui refuse de compiler mon projet (pb de templates et de STL). Et la, je suis confronté à un rigolo probleme : De nombreuses fonctions membres de classes wxXXX qui ont le meme nom dans l'API Windows se voient renomés a cause de #define liés à l'unicode.
Exemple : wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de
En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques Windows dans mon projet, sous peine de voir des fonctions renommées ? Cela m'ennuie car j'ai l'habitude de fonctionné avec OutputDebugString et DebugView.exe.
Existe t il une solution a mon probleme, ou bien dois-je desormais me
mettre
aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer : - soit placer le header qui subit l'autre au-dessus dans la séquence d'inclusions, - soit s'il en dépend aussi, le laisser en dessous mais faire un #undef UNICODE entre les deux.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif d'être compatible. En fait si le préprocesseur renomme TOUTES les occurences d'un nom de fonction, c'est sans importance, et transparent pour le programmeur. Par contre si vous recompilez partiellement et linkez un mix, vous vous aventurez en terrain miné.
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Hope It Helps,
Cordialement, PZB
Jeremie Fouche
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le message : 4110a103$0$16394$
Bonjour.
"Jeremie Fouche" a écrit dans le message de news:cenurr$882$ > Bonjour a tous > > Je suis confronté à un rigolo probleme : De nombreuses fonctions > membres de classes wxXXX qui ont le meme nom dans l'API Windows se
voient
> renomés a cause de #define liés à l'unicode. > > Exemple : > wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de > > #ifdef UNICODE > #define DrawText DrawTextW > #else > #define DrawText DrawTextA > #endif > dans winuser.h > > En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques > Windows dans mon projet, sous peine de voir des fonctions renommées ?
Cela
> m'ennuie car j'ai l'habitude de fonctionner avec OutputDebugString et > DebugView.exe. > > Existe t il une solution a mon probleme, ou bien dois-je desormais me mettre aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer : - soit placer le header qui subit l'autre au-dessus dans la séquence d'inclusions, - soit s'il en dépend aussi, le laisser en dessous mais faire un #undef UNICODE entre les deux.
Il me semble que cela ne changera rien, car il y a rennomage de chaque occurence de DrawText soit en DrawTextA soit en DrawTextW en fonction de la definition on non de UNICODE.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif d'être compatible. En fait si le préprocesseur renomme TOUTES les
occurences
d'un nom de fonction, c'est sans importance, et transparent pour le programmeur. Par contre si vous recompilez partiellement et linkez un mix, vous vous aventurez en terrain miné.
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++. Je vais faire d'autres test, bien qu'il me semble avoir penché pendant un moment sur une recompilallation partielle du projet. Il me semble donc avoir testé apres avoir viré tous les fichiers objets. A voir...
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Merci
-- Jérémie
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le
message : 4110a103$0$16394$626a14ce@news.free.fr...
Bonjour.
"Jeremie Fouche" <jeremie.fouche.tonmasque@tiscali.fr> a écrit dans le
message de news:cenurr$882$1@news.tiscali.fr...
> Bonjour a tous
>
> Je suis confronté à un rigolo probleme : De nombreuses fonctions
> membres de classes wxXXX qui ont le meme nom dans l'API Windows se
voient
> renomés a cause de #define liés à l'unicode.
>
> Exemple :
> wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de
>
> #ifdef UNICODE
> #define DrawText DrawTextW
> #else
> #define DrawText DrawTextA
> #endif
> dans winuser.h
>
> En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques
> Windows dans mon projet, sous peine de voir des fonctions renommées ?
Cela
> m'ennuie car j'ai l'habitude de fonctionner avec OutputDebugString et
> DebugView.exe.
>
> Existe t il une solution a mon probleme, ou bien dois-je desormais me
mettre aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer :
- soit placer le header qui subit l'autre au-dessus dans la séquence
d'inclusions,
- soit s'il en dépend aussi, le laisser en dessous mais faire un #undef
UNICODE entre les deux.
Il me semble que cela ne changera rien, car il y a rennomage de chaque
occurence de DrawText soit en DrawTextA soit en DrawTextW en fonction de la
definition on non de UNICODE.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif
d'être compatible. En fait si le préprocesseur renomme TOUTES les
occurences
d'un nom de fonction, c'est sans importance, et transparent pour le
programmeur. Par contre si vous recompilez partiellement et linkez un mix,
vous vous aventurez en terrain miné.
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++. Je
vais faire d'autres test, bien qu'il me semble avoir penché pendant un
moment sur une recompilallation partielle du projet. Il me semble donc avoir
testé apres avoir viré tous les fichiers objets. A voir...
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être
aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du
type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de
wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le message : 4110a103$0$16394$
Bonjour.
"Jeremie Fouche" a écrit dans le message de news:cenurr$882$ > Bonjour a tous > > Je suis confronté à un rigolo probleme : De nombreuses fonctions > membres de classes wxXXX qui ont le meme nom dans l'API Windows se
voient
> renomés a cause de #define liés à l'unicode. > > Exemple : > wxDC.DrawText(...) sera transformé en wxDC.DrawTextA(...) a cause de > > #ifdef UNICODE > #define DrawText DrawTextW > #else > #define DrawText DrawTextA > #endif > dans winuser.h > > En somme, je ne peut donc pas faire l'inclusion de fichiers specifiques > Windows dans mon projet, sous peine de voir des fonctions renommées ?
Cela
> m'ennuie car j'ai l'habitude de fonctionner avec OutputDebugString et > DebugView.exe. > > Existe t il une solution a mon probleme, ou bien dois-je desormais me mettre aux fonctionnalités de trace de wxWindows ?
J'ai déjà eu ce genre de problème, et il y a deux manières de le contrer : - soit placer le header qui subit l'autre au-dessus dans la séquence d'inclusions, - soit s'il en dépend aussi, le laisser en dessous mais faire un #undef UNICODE entre les deux.
Il me semble que cela ne changera rien, car il y a rennomage de chaque occurence de DrawText soit en DrawTextA soit en DrawTextW en fonction de la definition on non de UNICODE.
Cependant :
Je m'étonne un peu de cette incompatibilité, wxWindows ayant pour objectif d'être compatible. En fait si le préprocesseur renomme TOUTES les
occurences
d'un nom de fonction, c'est sans importance, et transparent pour le programmeur. Par contre si vous recompilez partiellement et linkez un mix, vous vous aventurez en terrain miné.
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++. Je vais faire d'autres test, bien qu'il me semble avoir penché pendant un moment sur une recompilallation partielle du projet. Il me semble donc avoir testé apres avoir viré tous les fichiers objets. A voir...
Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Merci
-- Jérémie
Patrick \Zener\ Brunet
Re bonjour.
"Jeremie Fouche" a écrit dans le message de news:cet992$fvc$
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le message : 4110a103$0$16394$ > Bonjour. > > "Jeremie Fouche" a écrit dans le > message de news:cenurr$882$ > > Bonjour a tous > > > > [...]
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++.
Je
vais faire d'autres test, bien qu'il me semble avoir penché pendant un moment sur une recompilallation partielle du projet. Il me semble donc
avoir
testé apres avoir viré tous les fichiers objets. A voir...
N'oubliez pas les .LIB et les .DLL !
> Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être > aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du > type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Il faut simplement vérifier dans les release notes de votre version de WX (et éventuellement chercher l'info sur le forum de l'équipe de développement) que UNICODE et la compilation conditionnelle "TCHAR" sont bien prévus. Il y a peut-être un paramétrage spécifique à faire, mais certainement pas de hack des headers. Si mes souvenirs du truc sont à jour, c'est bon.
Dans le pire des cas, restez en caractères simples au moins pour l'interface graphique, et ça ira bien.
De toute manière, ceci n'était qu'une diversion par rapport à votre problème fondamental : le renommage incomplet des fonctions.
Cordialement, PZB
Re bonjour.
"Jeremie Fouche" <jeremie.fouche.tonmasque@tiscali.fr> a écrit dans le
message de news:cet992$fvc$1@news.tiscali.fr...
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le
message : 4110a103$0$16394$626a14ce@news.free.fr...
> Bonjour.
>
> "Jeremie Fouche" <jeremie.fouche.tonmasque@tiscali.fr> a écrit dans le
> message de news:cenurr$882$1@news.tiscali.fr...
> > Bonjour a tous
> >
> > [...]
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++.
Je
vais faire d'autres test, bien qu'il me semble avoir penché pendant un
moment sur une recompilallation partielle du projet. Il me semble donc
avoir
testé apres avoir viré tous les fichiers objets. A voir...
N'oubliez pas les .LIB et les .DLL !
> Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être
> aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du
> type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de
wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Il faut simplement vérifier dans les release notes de votre version de WX
(et éventuellement chercher l'info sur le forum de l'équipe de
développement) que UNICODE et la compilation conditionnelle "TCHAR" sont
bien prévus. Il y a peut-être un paramétrage spécifique à faire, mais
certainement pas de hack des headers.
Si mes souvenirs du truc sont à jour, c'est bon.
Dans le pire des cas, restez en caractères simples au moins pour l'interface
graphique, et ça ira bien.
De toute manière, ceci n'était qu'une diversion par rapport à votre problème
fondamental : le renommage incomplet des fonctions.
"Jeremie Fouche" a écrit dans le message de news:cet992$fvc$
Patrick "Zener" Brunet <http://zener131.free.fr/ContactMe> a écrit dans le message : 4110a103$0$16394$ > Bonjour. > > "Jeremie Fouche" a écrit dans le > message de news:cenurr$882$ > > Bonjour a tous > > > > [...]
Ah tient, oui, effectivement. Je suis surpris du comportement de Dev-C++.
Je
vais faire d'autres test, bien qu'il me semble avoir penché pendant un moment sur une recompilallation partielle du projet. Il me semble donc
avoir
testé apres avoir viré tous les fichiers objets. A voir...
N'oubliez pas les .LIB et les .DLL !
> Je ne sais plus où en est wxWindows actuellement, mais il y a peut-être > aussi lieu de vérifier qu'il ne fait pas de suppositions malheureuses du > type LPTSTR = LPSTR, sinon vous aurez des problèmes à retardement.
Que faire dans ces conditions ? Modifier le header des definitions de wxWindow ? LA, je pense justement m'aventurer sur un terrain miné.
Il faut simplement vérifier dans les release notes de votre version de WX (et éventuellement chercher l'info sur le forum de l'équipe de développement) que UNICODE et la compilation conditionnelle "TCHAR" sont bien prévus. Il y a peut-être un paramétrage spécifique à faire, mais certainement pas de hack des headers. Si mes souvenirs du truc sont à jour, c'est bon.
Dans le pire des cas, restez en caractères simples au moins pour l'interface graphique, et ça ira bien.
De toute manière, ceci n'était qu'une diversion par rapport à votre problème fondamental : le renommage incomplet des fonctions.
Cordialement, PZB
Jeremie Fouche
J'ai avancé dans mon probleme, voir post sur fclc++
-- Jérémie
J'ai avancé dans mon probleme, voir post sur fclc++
