J'essaye d'écrire un serveur DDE en C++, mais sans les MFC,
plus précisément à l'aide de la STL.
Les exemples que j'ai trouvé jusqu'à présent sont :
1- Une source "C" fournie par la MSDN, dont je n'arrive pas à me
dépatouiller. C'est un peu le souk dans l'exemple fourni.
2- Une source «C++/MFC» que je n'arrive pas à traduire.(je ne maitrise pas
du tout les MFC).En fait, si, un peu mais ça finit par m'exploser dans les
mains à la deuxième tentative de connexion.
Est ce qu'une bonne âme aurait une classe de ce type sous la main, une aide ?
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne raison (j'allais dire excuse :-)) ) de programmer un serveur DDE alors que l'on peut faire beaucoup mieux et plus facilement avec un serveur Automation (COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ? C'est l'un des problèmes que j'ai rencontré plusieurs fois : faire cohabiter du MFC et du «non MFC» à base de windows.h.
Comment procéder dans ces cas là ?
D'après Patrick Philippot:
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne raison
(j'allais dire excuse :-)) ) de programmer un serveur DDE alors que l'on
peut faire beaucoup mieux et plus facilement avec un serveur Automation
(COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ?
C'est l'un des problèmes que j'ai rencontré plusieurs fois :
faire cohabiter du MFC et du «non MFC» à base de windows.h.
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne raison (j'allais dire excuse :-)) ) de programmer un serveur DDE alors que l'on peut faire beaucoup mieux et plus facilement avec un serveur Automation (COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ? C'est l'un des problèmes que j'ai rencontré plusieurs fois : faire cohabiter du MFC et du «non MFC» à base de windows.h.
Comment procéder dans ces cas là ?
Patrick Philippot
David MAREC wrote:
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne raison (j'allais dire excuse :-)) ) de programmer un serveur DDE alors que l'on peut faire beaucoup mieux et plus facilement avec un serveur Automation (COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients COM sans l'aide d'un framework n'est pas impossible mais c'est du masochisme et en tous cas contre-productif. Tous les outils de développement modernes sont livrés avec une encapsulation de ces mécanismes.
Quant à la cohabitation, rien n'empêche d'utiliser des DLLs non MFC depuis une appli MFC. Le contraire relevant également de la torture mentale sauf si ces DLLs exposent une interface standard de type C et que les MFC ne sont utilisées que pour le fonctionnement interne de la DLL.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne
raison (j'allais dire excuse :-)) ) de programmer un serveur DDE
alors que l'on peut faire beaucoup mieux et plus facilement avec un
serveur Automation (COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients
COM sans l'aide d'un framework n'est pas impossible mais c'est du
masochisme et en tous cas contre-productif. Tous les outils de
développement modernes sont livrés avec une encapsulation de ces
mécanismes.
Quant à la cohabitation, rien n'empêche d'utiliser des DLLs non MFC
depuis une appli MFC. Le contraire relevant également de la torture
mentale sauf si ces DLLs exposent une interface standard de type C et
que les MFC ne sont utilisées que pour le fonctionnement interne de la
DLL.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Ceci étant, Arnaud a raison. Aujourd'hui, il n'y a aucune bonne raison (j'allais dire excuse :-)) ) de programmer un serveur DDE alors que l'on peut faire beaucoup mieux et plus facilement avec un serveur Automation (COM). Surtout en MFC, c'est immédiat.
Oui, mais sans les MFC ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients COM sans l'aide d'un framework n'est pas impossible mais c'est du masochisme et en tous cas contre-productif. Tous les outils de développement modernes sont livrés avec une encapsulation de ces mécanismes.
Quant à la cohabitation, rien n'empêche d'utiliser des DLLs non MFC depuis une appli MFC. Le contraire relevant également de la torture mentale sauf si ces DLLs exposent une interface standard de type C et que les MFC ne sont utilisées que pour le fonctionnement interne de la DLL.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
David MAREC wrote:
Si je ne force pas le format lors du DDECreateDataHandle(), le client DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui renvois. (Excel m'affiche #NOM?)
Justement, avez vous vu cet article: HOWTO: Write a DDEML Server for Excel and Use it with NetDDE Q238133
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des exemples de code, la doc éparses des fonctions à utiliser et une courte introduction sur le site de Microsoft. Ceci reste incompréhensible sans les spécifications du protocole.
Tout ça est complètement décrit et en détails dans le MSDN: Platform SDK Documentation Base Services Interprocess Communications Dynamic Data Exchange
Le DDE est également décortiqué dans le Petzold, enfin, dans les anciennes éditions. Voir aussi:
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
Si je ne force pas le format lors du DDECreateDataHandle(), le client
DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui
renvois. (Excel m'affiche #NOM?)
Justement, avez vous vu cet article:
HOWTO: Write a DDEML Server for Excel and Use it with NetDDE
Q238133
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des
exemples de code, la doc éparses des fonctions à utiliser et une
courte introduction sur le site de Microsoft.
Ceci reste incompréhensible sans les spécifications du protocole.
Tout ça est complètement décrit et en détails dans le MSDN:
Platform SDK Documentation
Base Services
Interprocess Communications
Dynamic Data Exchange
Le DDE est également décortiqué dans le Petzold, enfin, dans les
anciennes éditions. Voir aussi:
Si je ne force pas le format lors du DDECreateDataHandle(), le client DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui renvois. (Excel m'affiche #NOM?)
Justement, avez vous vu cet article: HOWTO: Write a DDEML Server for Excel and Use it with NetDDE Q238133
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des exemples de code, la doc éparses des fonctions à utiliser et une courte introduction sur le site de Microsoft. Ceci reste incompréhensible sans les spécifications du protocole.
Tout ça est complètement décrit et en détails dans le MSDN: Platform SDK Documentation Base Services Interprocess Communications Dynamic Data Exchange
Le DDE est également décortiqué dans le Petzold, enfin, dans les anciennes éditions. Voir aussi:
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Arnaud Debaene
David MAREC wrote:
D'après Patrick Philippot:
Certes, mais comment gérer le format dans ce cas ? Si je ne précise pas CF_TEXT, rien ne bouge.
Ce qui veut dire? Avez vous regardé ce que retourne DdeGetLastError ? Nous ne pouvons pas répondre avec si peu d'informations.
- Je décris tout ce qui suit de mémoire. -
Si je ne force pas le format lors du DDECreateDataHandle(), le client DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui renvois. (Excel m'affiche #NOM?) D'où ma question sur la gestion types en DDE.
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des exemples de code, la doc éparses des fonctions à utiliser et une courte introduction sur le site de Microsoft. Ceci reste incompréhensible sans les spécifications du protocole.
Sauf erreur de ma part, le format des données à passer à Excel est là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/S100FF.asp?frame=true
Et il y a aussi cet article : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true, mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
Arnaud MVP - VC
David MAREC wrote:
D'après Patrick Philippot:
Certes, mais comment gérer le format dans ce cas ?
Si je ne précise pas CF_TEXT, rien ne bouge.
Ce qui veut dire? Avez vous regardé ce que retourne DdeGetLastError ?
Nous ne pouvons pas répondre avec si peu d'informations.
- Je décris tout ce qui suit de mémoire. -
Si je ne force pas le format lors du DDECreateDataHandle(), le client
DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui
renvois. (Excel m'affiche #NOM?)
D'où ma question sur la gestion types en DDE.
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des
exemples de code, la doc éparses des fonctions à utiliser et une
courte introduction sur le site de Microsoft.
Ceci reste incompréhensible sans les spécifications du protocole.
Sauf erreur de ma part, le format des données à passer à Excel est là :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/S100FF.asp?frame=true
Et il y a aussi cet article :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true,
mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
Certes, mais comment gérer le format dans ce cas ? Si je ne précise pas CF_TEXT, rien ne bouge.
Ce qui veut dire? Avez vous regardé ce que retourne DdeGetLastError ? Nous ne pouvons pas répondre avec si peu d'informations.
- Je décris tout ce qui suit de mémoire. -
Si je ne force pas le format lors du DDECreateDataHandle(), le client DDE n'arrive pas apparemment à comprendre le contenu de ce que je lui renvois. (Excel m'affiche #NOM?) D'où ma question sur la gestion types en DDE.
Je n'ai pas trouvé la moindre Doc, le moindre Tutorial, juste des exemples de code, la doc éparses des fonctions à utiliser et une courte introduction sur le site de Microsoft. Ceci reste incompréhensible sans les spécifications du protocole.
Sauf erreur de ma part, le format des données à passer à Excel est là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/S100FF.asp?frame=true
Et il y a aussi cet article : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true, mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
Arnaud MVP - VC
David MAREC
D'après Arnaud Debaene :
Et il y a aussi cet article : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true, mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
C'est exact. C'est à partir ce cette classe que j'ai tenté de faire fonctionner mon serveur.
D'après Arnaud Debaene :
Et il y a aussi cet article :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true,
mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
C'est exact.
C'est à partir ce cette classe que j'ai tenté de faire fonctionner mon
serveur.
Et il y a aussi cet article : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_ddeplus.asp?frame=true, mais c'est peut être ce à quoitu faisais référence dans ton 1et message?
C'est exact. C'est à partir ce cette classe que j'ai tenté de faire fonctionner mon serveur.
David MAREC
Salutations cordiales !
[Je change de sujet]
Patrick Philippot me disait:
>>[COM DCOM et autres technologies]
Oui, mais sans les MFC ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients COM sans l'aide d'un framework n'est pas impossible mais c'est du masochisme et en tous cas contre-productif.
Dommage. Dans mon secteur, par exemple, j'utilise beaucoup d'interfaces et de codes plus ou moins anciens, voire même programmés pour DOS, utilisant en majorité <windows.h> et autres.
Qu'est ce qui est réellement contre-productif ?
[ ] Réécrire tous ces modules ? qui sont aussi des technologies, ce qui demande toutes les opérations de débuggage et de test en plateforme que ça implique.
[ ] Les adaptés et les embarquer dans une DLL, ce qui demande les mêmes contraintes que précédemment, finalement. Sans compter que débugger une DLL n'est pas ce qu'il y a de plus aisé.
[ ] Ne pas utiliser de framework et se taper un code de cauchemard. (C'est d'ailleurs écrit sur le site principal que vous m'avez indiqé : Creating a dynamic data exchange (DDE) server from scratch or adding DDE server support to an existing application can be a real nightmare)
Sans compter que peu de technologies sont libres dans mon domaine.
De plus, ces technologies enferment le développeur, il ne peut plus utiliser ensuite les wxWidgets par exemple, ou autres bibliothèques.
De mon coté, cela requiert une formation et l'achat d'ouvrage sur ces technologies. J'en ai effectivement feuilleté quelques un et tout est écrit à l'aide de MFC, .NET ...
Je ne connais pas .NET et les MFC me semble exagérement compliquées pour la plupart des applications; hors l'encapsulation de technologies ardues sujets de ce fil, bien entendu.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ? Quel est l'avantage de ce dernier en particulier ?
Salutations cordiales !
[Je change de sujet]
Patrick Philippot me disait:
>>[COM DCOM et autres technologies]
Oui, mais sans les MFC ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients
COM sans l'aide d'un framework n'est pas impossible mais c'est du
masochisme et en tous cas contre-productif.
Dommage.
Dans mon secteur, par exemple, j'utilise beaucoup d'interfaces et de
codes plus ou moins anciens, voire même programmés pour DOS, utilisant
en majorité <windows.h> et autres.
Qu'est ce qui est réellement contre-productif ?
[ ] Réécrire tous ces modules ?
qui sont aussi des technologies, ce qui demande toutes les
opérations de débuggage et de test en plateforme que ça
implique.
[ ] Les adaptés et les embarquer dans une DLL, ce qui demande les
mêmes contraintes que précédemment, finalement.
Sans compter que débugger une DLL n'est pas ce qu'il y a de plus
aisé.
[ ] Ne pas utiliser de framework et se taper un code de cauchemard.
(C'est d'ailleurs écrit sur le site principal que vous m'avez
indiqé :
Creating a dynamic data exchange (DDE) server from scratch or
adding DDE server support to an existing application can be a
real nightmare)
Sans compter que peu de technologies sont libres dans mon domaine.
De plus, ces technologies enferment le développeur, il ne peut plus
utiliser ensuite les wxWidgets par exemple, ou autres bibliothèques.
De mon coté, cela requiert une formation et l'achat d'ouvrage sur ces
technologies.
J'en ai effectivement feuilleté quelques un et tout est écrit à l'aide
de MFC, .NET ...
Je ne connais pas .NET et les MFC me semble exagérement compliquées pour
la plupart des applications; hors l'encapsulation de technologies ardues
sujets de ce fil, bien entendu.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ?
Quel est l'avantage de ce dernier en particulier ?
ATL ou vous oubliez. La construction directe de serveurs ou de clients COM sans l'aide d'un framework n'est pas impossible mais c'est du masochisme et en tous cas contre-productif.
Dommage. Dans mon secteur, par exemple, j'utilise beaucoup d'interfaces et de codes plus ou moins anciens, voire même programmés pour DOS, utilisant en majorité <windows.h> et autres.
Qu'est ce qui est réellement contre-productif ?
[ ] Réécrire tous ces modules ? qui sont aussi des technologies, ce qui demande toutes les opérations de débuggage et de test en plateforme que ça implique.
[ ] Les adaptés et les embarquer dans une DLL, ce qui demande les mêmes contraintes que précédemment, finalement. Sans compter que débugger une DLL n'est pas ce qu'il y a de plus aisé.
[ ] Ne pas utiliser de framework et se taper un code de cauchemard. (C'est d'ailleurs écrit sur le site principal que vous m'avez indiqé : Creating a dynamic data exchange (DDE) server from scratch or adding DDE server support to an existing application can be a real nightmare)
Sans compter que peu de technologies sont libres dans mon domaine.
De plus, ces technologies enferment le développeur, il ne peut plus utiliser ensuite les wxWidgets par exemple, ou autres bibliothèques.
De mon coté, cela requiert une formation et l'achat d'ouvrage sur ces technologies. J'en ai effectivement feuilleté quelques un et tout est écrit à l'aide de MFC, .NET ...
Je ne connais pas .NET et les MFC me semble exagérement compliquées pour la plupart des applications; hors l'encapsulation de technologies ardues sujets de ce fil, bien entendu.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ? Quel est l'avantage de ce dernier en particulier ?
David MAREC
D'après Patrick Philippot:
> [Documentation]
Tout ça est complètement décrit et en détails dans le MSDN: Platform SDK Documentation Base Services Interprocess Communications Dynamic Data Exchange
Ce chapitre concerne surtout le client.
Seul le chapitre Dynamic Data Exchange Management Library décrit vraiment le serveur.
Mais c'est assez succint, il me manque des précisions sur l'utilisation des formats.
Ceci dit, j'ai écrit un truc qui semble fonctionner, il me reste un détail curieux, peut-être spécifique à VC++6.
Je vous l'expose quand même, on ne sait jamais... :-)
J'ai donc une fonction dite "Callback" (*) qui appele selon le "topic" une fonction qui lui retourne un HDDEDATA ainsi: (j'ai pompé une partie du code)
/* euh dois je le faire ça ? ????????? */ DdeFreeDataHandle(hDataStatus[iFmt]);
} return(hData);
/***************************/
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
(*) mais comment fait on les guillemets sur un clavier de portable et sous XP ?
D'après Patrick Philippot:
> [Documentation]
Tout ça est complètement décrit et en détails dans le MSDN:
Platform SDK Documentation
Base Services
Interprocess Communications
Dynamic Data Exchange
Ce chapitre concerne surtout le client.
Seul le chapitre
Dynamic Data Exchange Management Library
décrit vraiment le serveur.
Mais c'est assez succint, il me manque des précisions sur l'utilisation
des formats.
Ceci dit, j'ai écrit un truc qui semble fonctionner, il me reste un
détail curieux, peut-être spécifique à VC++6.
Je vous l'expose quand même, on ne sait jamais... :-)
J'ai donc une fonction dite "Callback" (*) qui appele selon le "topic"
une fonction qui lui retourne un HDDEDATA ainsi: (j'ai pompé une partie
du code)
/*
euh dois je le faire ça ?
?????????
*/
DdeFreeDataHandle(hDataStatus[iFmt]);
}
return(hData);
/***************************/
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête
tout seul sur un "user breakpoint" dans un code qui n'est pas le mien
(assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
(*) mais comment fait on les guillemets sur un clavier de portable et
sous XP ?
Tout ça est complètement décrit et en détails dans le MSDN: Platform SDK Documentation Base Services Interprocess Communications Dynamic Data Exchange
Ce chapitre concerne surtout le client.
Seul le chapitre Dynamic Data Exchange Management Library décrit vraiment le serveur.
Mais c'est assez succint, il me manque des précisions sur l'utilisation des formats.
Ceci dit, j'ai écrit un truc qui semble fonctionner, il me reste un détail curieux, peut-être spécifique à VC++6.
Je vous l'expose quand même, on ne sait jamais... :-)
J'ai donc une fonction dite "Callback" (*) qui appele selon le "topic" une fonction qui lui retourne un HDDEDATA ainsi: (j'ai pompé une partie du code)
/* euh dois je le faire ça ? ????????? */ DdeFreeDataHandle(hDataStatus[iFmt]);
} return(hData);
/***************************/
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
(*) mais comment fait on les guillemets sur un clavier de portable et sous XP ?
David MAREC
> Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
> Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête
tout seul sur un "user breakpoint" dans un code qui n'est pas le mien
(assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche :
HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past
requested size of e
HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000,
0014C9F0 )
> Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
Patrick Philippot
David MAREC wrote:
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
Je dirais à vue de nez: buffer overrun.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête
tout seul sur un "user breakpoint" dans un code qui n'est pas le mien
(assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche :
HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past
requested size of e
HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000,
0014C9F0 )
Je dirais à vue de nez: buffer overrun.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Bizarrement, si donnee.truc a une grande valeur, le débugger s'arrête tout seul sur un "user breakpoint" dans un code qui n'est pas le mien (assembleur) , à la sortie du callback !?
Tout semble fonctionner sans débuggeur.
Qu'est ce qui se passe-t-il donc ?
Pour être plus précis, il me semble que c'est dans NTDLL.DLL
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
Je dirais à vue de nez: buffer overrun.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC
Selon Patrick Philippot :
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
Je dirais à vue de nez: buffer overrun.
Euh, comme cela ne "semble" (soyons prudent) géner que le debugger, sans qu'il plante ceci dit, mais la liaison DDE ne fonctionne plus, dois-je configurer quelque chose ?
Peut-on trouver de quel buffer, il s'agit ?
Merci de votre attention.
Selon Patrick Philippot :
et le débugger affiche :
HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past
requested size of e
HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000,
0014C9F0 )
Je dirais à vue de nez: buffer overrun.
Euh, comme cela ne "semble" (soyons prudent) géner que le debugger, sans
qu'il plante ceci dit, mais la liaison DDE ne fonctionne plus, dois-je
configurer quelque chose ?
et le débugger affiche : HEAP[test7.exe]: Heap block at 0014C9E8 modified at 0014C9FE past requested size of e HEAP[test7.exe]: Invalid Address specified to RtlSizeHeap( 00140000, 0014C9F0 )
Je dirais à vue de nez: buffer overrun.
Euh, comme cela ne "semble" (soyons prudent) géner que le debugger, sans qu'il plante ceci dit, mais la liaison DDE ne fonctionne plus, dois-je configurer quelque chose ?
