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 ?
Qu'est ce qui est réellement contre-productif ? [ ] Réécrire tous ces modules ? [ ] Les adaptés et les embarquer dans une DLL, [ ] Ne pas utiliser de framework et se taper un code de cauchemard.
Je parle de la création d'un serveur COM (ce qui n'a rien à voir avec un serveur DDE - ça le remplace). On peut écrire un serveur COM en partant de rien mais cela suppose une connaissance approfondie de tous les mécanismes du COM, ce qui prend des mois à assimiler. Puis des mois pour écrire le code. Absolument *personne* ne fait ça aujourd'hui en production. Les seules personnes qui écrivent un tel code sont celles qui fabriquent les outils de développement et vous fournissent une encapsulation via ATL ou les MFC ou Delphi, etc.
Enfin, puisque vous nous dîtes que le client ne fonctionne qu'avec DDE, pas question de COM pour le moment. Mais bon, il faudrait que quelqu'un bouge, là... :-)
En ce qui concerne le DDE:
Le protocole est mal fichu mais pas compliqué. Une fois que l'on a compris qu'il est basé sur des échanges de messages entre fenêtres, il suffit de regarder la doc de chaque message WM_DDE_xxx (il n'y en a que 9) et on a vite fait le tour. Ce qui pose problème ce sont les "trous" dans ce design.
DDEML ne fait qu'encapsuler cette mécanique en gérant elle-même ces messages et en créant de manière transparente des fenêtres... invisibles entre lesquelles ces messages sont échangés.
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.
Si les MFC compliquaient la vie des développeurs au lieu de la simplifier, ça se saurait et il n'y aurait pas autant d'utilisateurs. Elles sont utilisées pour un grand nombre d'applications très diverses et par des sociétés de grande taille. Il ne faut pas confondre 2 choses:
- La qualité du design objet des MFC qui est criticable. Le modèle vue/document n'est qu'un sous-ensemble d'une architecture plus pertinente connue sous le nom de modèle MVC (Modèle-Vue-Contrôleur) dont il existe d'ailleurs des implémentation connectables sur les MFC (voir Stingray Studio chez Roguewave). Cette simplification crée des problèmes surtout dans le cas d'applications un peu lourdes. Mais ils sont gérables. Par ailleurs, les MFC se traînent quelques "casseroles" qui sont dues à son historique (elles existent depuis VC++ 1.0 16-bit), notammment le fait que de nombreuses méthodes dans certaines classes devraient être virtuelles et qu'elles ne le sont pas, pour cause d'encombrement mémoire à l'époque du 16-bit.
- La simplification apportée dans l'écriture des applications. Évidemment, il faut faire l'effort de se familiariser avec cette mécanique mais le gain est évident, toutes considérations confondues.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ? Quel est l'avantage de ce dernier en particulier ?
L'objectif des MFC est, entre autres, d'éliminer les tâches répétitives de la programmation Windows. Ces mécanismes (comme par exemple la création de window procedures) sont encapsulés une bonne fois pour toutes dans le code source du framework. En particulier, dans les MFC un message Windows est directement traité par un handler. Vous choisissez le message dans le Class Wizard et vous n'avez plus qu'à écrire le code du handler. La connexion est automatique. Mais il faut bien que le framework se charge de manière transparente d'assurer cette connexion, de gérer le message entre le moment où il arrive dans la boucle GetMessage (également masquée) et le moment où il parvient à votre handler. C'est le but de toutes les macros que vous voyez dans votre code. Elles permettent aux MFC de gérer des tables de dispatching des messages.
Tout cela est expliqué dans la documentation des MFC et dans tout ouvrage sur le sujet. Voir par exemple "Professional MFC with Visual C++" de Mike Blaszczak, chez Wrox. cela demande un investissement. Si vous ne le faites pas, vous en resterez à vous poser des questions sur le pourquoi du comment. Si vous le faites, vous vous apercevrez que cela n'a pas été du temps perdu. Si vous voulez comprendre les MFC à plus bas niveau: "MFC Internals" de Shepherd et Wingo chez Addison-Wesley et le livre de Jeff Prosise sur les MFC chez Microsoft Press (je n'ai pas le titre en tête).
Malgré les critiques souvent légitimes que l'on peut faire aux MFC, elles rendent service. Sans aucun doute. J'ai connu de meilleurs frameworks du même type, en particulier OWL de Borland, abandonnée depuis (une grave erreur). Donc sans être un fana des MFCs, je reconnais le service rendu. Je les ai enseignées dans de grandes entreprises et elles sont toujours en cours d'utilisation, sans problème particulier. Je les ai utilisées pour de nombreux projets chez mes clients et je n'ai pas eu à le regretter, globalement.
Tout cela, en attendant la migration inéluctable vers .Net dont le seul défaut majeur à mon sens est de ne pas proposer aujourd' hui de framework équivalent, même si des efforts dans ce sens sont faits chez Microsoft (voir l'Architecture Center: http://msdn.microsoft.com/architecture/).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
Qu'est ce qui est réellement contre-productif ?
[ ] Réécrire tous ces modules ?
[ ] Les adaptés et les embarquer dans une DLL,
[ ] Ne pas utiliser de framework et se taper un code de cauchemard.
Je parle de la création d'un serveur COM (ce qui n'a rien à voir avec un
serveur DDE - ça le remplace). On peut écrire un serveur COM en partant
de rien mais cela suppose une connaissance approfondie de tous les
mécanismes du COM, ce qui prend des mois à assimiler. Puis des mois pour
écrire le code. Absolument *personne* ne fait ça aujourd'hui en
production. Les seules personnes qui écrivent un tel code sont celles
qui fabriquent les outils de développement et vous fournissent une
encapsulation via ATL ou les MFC ou Delphi, etc.
Enfin, puisque vous nous dîtes que le client ne fonctionne qu'avec DDE,
pas question de COM pour le moment. Mais bon, il faudrait que quelqu'un
bouge, là... :-)
En ce qui concerne le DDE:
Le protocole est mal fichu mais pas compliqué. Une fois que l'on a
compris qu'il est basé sur des échanges de messages entre fenêtres, il
suffit de regarder la doc de chaque message WM_DDE_xxx (il n'y en a que
9) et on a vite fait le tour. Ce qui pose problème ce sont les "trous"
dans ce design.
DDEML ne fait qu'encapsuler cette mécanique en gérant elle-même ces
messages et en créant de manière transparente des fenêtres... invisibles
entre lesquelles ces messages sont échangés.
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.
Si les MFC compliquaient la vie des développeurs au lieu de la
simplifier, ça se saurait et il n'y aurait pas autant d'utilisateurs.
Elles sont utilisées pour un grand nombre d'applications très diverses
et par des sociétés de grande taille. Il ne faut pas confondre 2 choses:
- La qualité du design objet des MFC qui est criticable. Le modèle
vue/document n'est qu'un sous-ensemble d'une architecture plus
pertinente connue sous le nom de modèle MVC (Modèle-Vue-Contrôleur) dont
il existe d'ailleurs des implémentation connectables sur les MFC (voir
Stingray Studio chez Roguewave). Cette simplification crée des problèmes
surtout dans le cas d'applications un peu lourdes. Mais ils sont
gérables. Par ailleurs, les MFC se traînent quelques "casseroles" qui
sont dues à son historique (elles existent depuis VC++ 1.0 16-bit),
notammment le fait que de nombreuses méthodes dans certaines classes
devraient être virtuelles et qu'elles ne le sont pas, pour cause
d'encombrement mémoire à l'époque du 16-bit.
- La simplification apportée dans l'écriture des applications.
Évidemment, il faut faire l'effort de se familiariser avec cette
mécanique mais le gain est évident, toutes considérations confondues.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ?
Quel est l'avantage de ce dernier en particulier ?
L'objectif des MFC est, entre autres, d'éliminer les tâches répétitives
de la programmation Windows. Ces mécanismes (comme par exemple la
création de window procedures) sont encapsulés une bonne fois pour
toutes dans le code source du framework. En particulier, dans les MFC un
message Windows est directement traité par un handler. Vous choisissez
le message dans le Class Wizard et vous n'avez plus qu'à écrire le code
du handler. La connexion est automatique. Mais il faut bien que le
framework se charge de manière transparente d'assurer cette connexion,
de gérer le message entre le moment où il arrive dans la boucle
GetMessage (également masquée) et le moment où il parvient à votre
handler. C'est le but de toutes les macros que vous voyez dans votre
code. Elles permettent aux MFC de gérer des tables de dispatching des
messages.
Tout cela est expliqué dans la documentation des MFC et dans tout
ouvrage sur le sujet. Voir par exemple "Professional MFC with Visual
C++" de Mike Blaszczak, chez Wrox. cela demande un investissement. Si
vous ne le faites pas, vous en resterez à vous poser des questions sur
le pourquoi du comment. Si vous le faites, vous vous apercevrez que cela
n'a pas été du temps perdu. Si vous voulez comprendre les MFC à plus bas
niveau: "MFC Internals" de Shepherd et Wingo chez Addison-Wesley et le
livre de Jeff Prosise sur les MFC chez Microsoft Press (je n'ai pas le
titre en tête).
Malgré les critiques souvent légitimes que l'on peut faire aux MFC,
elles rendent service. Sans aucun doute. J'ai connu de meilleurs
frameworks du même type, en particulier OWL de Borland, abandonnée
depuis (une grave erreur). Donc sans être un fana des MFCs, je reconnais
le service rendu. Je les ai enseignées dans de grandes entreprises et
elles sont toujours en cours d'utilisation, sans problème particulier.
Je les ai utilisées pour de nombreux projets chez mes clients et je n'ai
pas eu à le regretter, globalement.
Tout cela, en attendant la migration inéluctable vers .Net dont le seul
défaut majeur à mon sens est de ne pas proposer aujourd' hui de
framework équivalent, même si des efforts dans ce sens sont faits chez
Microsoft (voir l'Architecture Center:
http://msdn.microsoft.com/architecture/).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Qu'est ce qui est réellement contre-productif ? [ ] Réécrire tous ces modules ? [ ] Les adaptés et les embarquer dans une DLL, [ ] Ne pas utiliser de framework et se taper un code de cauchemard.
Je parle de la création d'un serveur COM (ce qui n'a rien à voir avec un serveur DDE - ça le remplace). On peut écrire un serveur COM en partant de rien mais cela suppose une connaissance approfondie de tous les mécanismes du COM, ce qui prend des mois à assimiler. Puis des mois pour écrire le code. Absolument *personne* ne fait ça aujourd'hui en production. Les seules personnes qui écrivent un tel code sont celles qui fabriquent les outils de développement et vous fournissent une encapsulation via ATL ou les MFC ou Delphi, etc.
Enfin, puisque vous nous dîtes que le client ne fonctionne qu'avec DDE, pas question de COM pour le moment. Mais bon, il faudrait que quelqu'un bouge, là... :-)
En ce qui concerne le DDE:
Le protocole est mal fichu mais pas compliqué. Une fois que l'on a compris qu'il est basé sur des échanges de messages entre fenêtres, il suffit de regarder la doc de chaque message WM_DDE_xxx (il n'y en a que 9) et on a vite fait le tour. Ce qui pose problème ce sont les "trous" dans ce design.
DDEML ne fait qu'encapsuler cette mécanique en gérant elle-même ces messages et en créant de manière transparente des fenêtres... invisibles entre lesquelles ces messages sont échangés.
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.
Si les MFC compliquaient la vie des développeurs au lieu de la simplifier, ça se saurait et il n'y aurait pas autant d'utilisateurs. Elles sont utilisées pour un grand nombre d'applications très diverses et par des sociétés de grande taille. Il ne faut pas confondre 2 choses:
- La qualité du design objet des MFC qui est criticable. Le modèle vue/document n'est qu'un sous-ensemble d'une architecture plus pertinente connue sous le nom de modèle MVC (Modèle-Vue-Contrôleur) dont il existe d'ailleurs des implémentation connectables sur les MFC (voir Stingray Studio chez Roguewave). Cette simplification crée des problèmes surtout dans le cas d'applications un peu lourdes. Mais ils sont gérables. Par ailleurs, les MFC se traînent quelques "casseroles" qui sont dues à son historique (elles existent depuis VC++ 1.0 16-bit), notammment le fait que de nombreuses méthodes dans certaines classes devraient être virtuelles et qu'elles ne le sont pas, pour cause d'encombrement mémoire à l'époque du 16-bit.
- La simplification apportée dans l'écriture des applications. Évidemment, il faut faire l'effort de se familiariser avec cette mécanique mais le gain est évident, toutes considérations confondues.
Pourquoi par exemple, tout ces CObject, IMPLEMENT_DYNCREATE ? Quel est l'avantage de ce dernier en particulier ?
L'objectif des MFC est, entre autres, d'éliminer les tâches répétitives de la programmation Windows. Ces mécanismes (comme par exemple la création de window procedures) sont encapsulés une bonne fois pour toutes dans le code source du framework. En particulier, dans les MFC un message Windows est directement traité par un handler. Vous choisissez le message dans le Class Wizard et vous n'avez plus qu'à écrire le code du handler. La connexion est automatique. Mais il faut bien que le framework se charge de manière transparente d'assurer cette connexion, de gérer le message entre le moment où il arrive dans la boucle GetMessage (également masquée) et le moment où il parvient à votre handler. C'est le but de toutes les macros que vous voyez dans votre code. Elles permettent aux MFC de gérer des tables de dispatching des messages.
Tout cela est expliqué dans la documentation des MFC et dans tout ouvrage sur le sujet. Voir par exemple "Professional MFC with Visual C++" de Mike Blaszczak, chez Wrox. cela demande un investissement. Si vous ne le faites pas, vous en resterez à vous poser des questions sur le pourquoi du comment. Si vous le faites, vous vous apercevrez que cela n'a pas été du temps perdu. Si vous voulez comprendre les MFC à plus bas niveau: "MFC Internals" de Shepherd et Wingo chez Addison-Wesley et le livre de Jeff Prosise sur les MFC chez Microsoft Press (je n'ai pas le titre en tête).
Malgré les critiques souvent légitimes que l'on peut faire aux MFC, elles rendent service. Sans aucun doute. J'ai connu de meilleurs frameworks du même type, en particulier OWL de Borland, abandonnée depuis (une grave erreur). Donc sans être un fana des MFCs, je reconnais le service rendu. Je les ai enseignées dans de grandes entreprises et elles sont toujours en cours d'utilisation, sans problème particulier. Je les ai utilisées pour de nombreux projets chez mes clients et je n'ai pas eu à le regretter, globalement.
Tout cela, en attendant la migration inéluctable vers .Net dont le seul défaut majeur à mon sens est de ne pas proposer aujourd' hui de framework équivalent, même si des efforts dans ce sens sont faits chez Microsoft (voir l'Architecture Center: http://msdn.microsoft.com/architecture/).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
David MAREC wrote:
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 )
Regardez le premier message d'erreur: on dirait bien que vous écrivez au-delà de la taille autorisée à l'adresse de la variable e (si le message est complet). Il s'agit d'une variable allouée sur le tas à l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce qui ne semble pas autorisé, le bloc étant probablement plus court. Cela devrait être facile à repérer dans le débogueur au moment de l'erreur. Utilisez la fenêtre de debug Memory et allez à cette adresse.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
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 )
Regardez le premier message d'erreur: on dirait bien que vous écrivez
au-delà de la taille autorisée à l'adresse de la variable e (si le
message est complet). Il s'agit d'une variable allouée sur le tas à
l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce
qui ne semble pas autorisé, le bloc étant probablement plus court. Cela
devrait être facile à repérer dans le débogueur au moment de l'erreur.
Utilisez la fenêtre de debug Memory et allez à cette adresse.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
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 )
Regardez le premier message d'erreur: on dirait bien que vous écrivez au-delà de la taille autorisée à l'adresse de la variable e (si le message est complet). Il s'agit d'une variable allouée sur le tas à l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce qui ne semble pas autorisé, le bloc étant probablement plus court. Cela devrait être facile à repérer dans le débogueur au moment de l'erreur. Utilisez la fenêtre de debug Memory et allez à cette adresse.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC
Selon Patrick Philippot:
Il s'agit d'une variable allouée sur le tas à l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce qui ne semble pas autorisé, le bloc étant probablement plus court.
Cela devrait être facile à repérer dans le débogueur au moment de l'erreur. Utilisez la fenêtre de debug Memory et allez à cette adresse.
C'est exact, il s'agit bien de la valeur de ma variable d'échange créée par
Tout se déroule sans soucis. Et l'erreur se produit ailleurs, dans ntdll.dll. En Execution "normale" sans le debuggeur, aucune anomalie (de façade) mais ce n'est pas rassurant.
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
Merci de votre concours.
Selon Patrick Philippot:
Il s'agit d'une variable allouée sur le tas à
l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce
qui ne semble pas autorisé, le bloc étant probablement plus court.
Cela
devrait être facile à repérer dans le débogueur au moment de l'erreur.
Utilisez la fenêtre de debug Memory et allez à cette adresse.
C'est exact, il s'agit bien de la valeur de ma variable d'échange créée par
Tout se déroule sans soucis.
Et l'erreur se produit ailleurs, dans ntdll.dll.
En Execution "normale" sans le debuggeur, aucune anomalie (de façade)
mais ce n'est pas rassurant.
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
Il s'agit d'une variable allouée sur le tas à l'adresse 0014C9E8 et il y a eu une tentative d'écriture à 0014C9FE, ce qui ne semble pas autorisé, le bloc étant probablement plus court.
Cela devrait être facile à repérer dans le débogueur au moment de l'erreur. Utilisez la fenêtre de debug Memory et allez à cette adresse.
C'est exact, il s'agit bien de la valeur de ma variable d'échange créée par
Tout se déroule sans soucis. Et l'erreur se produit ailleurs, dans ntdll.dll. En Execution "normale" sans le debuggeur, aucune anomalie (de façade) mais ce n'est pas rassurant.
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
Et l'erreur se produit ailleurs, dans ntdll.dll. Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
C'est bien pratique de décrire son problème par écrit, on trouve la réponse en se relisant.
Patrick Philippot
David MAREC wrote:
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
L'objectif du DDE est d'échanger des données entre processus. Or sous Win32, un pointeur sur un bloc mémoire valide dans un processus n'a aucune signification pour l'autre processus. On ne peut donc échanger des pointeurs entre processus. DdeCreateDataHandle permet donc de dupliquer les données dans un bloc mémoire partagé représenté par le handle et qui sera accessible au client.
Le paramètre offset permet de ne copier les données qu'à partir d'un certain... offset dans le buffer. C'est juste une commodité qui permet de travailler avec une adresse de base invariable et de faire varier l'endroit à partir duquel on transfère les données. C'est bien sûr vous même qui décidez de sa signification et de la pertinence de son utilisation. Donc c'est vous qui savez pourquoi vous utilisez un offset de 10 :-) .
En Execution "normale" sans le debuggeur, aucune anomalie (de façade) mais ce n'est pas rassurant..
C'est le signe caractéristique d'un pointeur ou d'une adresse invalide ou d'un écrasement de zone mémoire. En mode debug, certains contrôles sont réalisés par VS. En particulier, les allocations mémoires sont supervisées et gérées par un code différent (un allocateur mémoire différent), ce qui permet de détecter les anomalies. En mode release ou en dehors du débogueur, ce contrôle n'existe pas.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David MAREC wrote:
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
L'objectif du DDE est d'échanger des données entre processus. Or sous
Win32, un pointeur sur un bloc mémoire valide dans un processus n'a
aucune signification pour l'autre processus. On ne peut donc échanger
des pointeurs entre processus. DdeCreateDataHandle permet donc de
dupliquer les données dans un bloc mémoire partagé représenté par le
handle et qui sera accessible au client.
Le paramètre offset permet de ne copier les données qu'à partir d'un
certain... offset dans le buffer. C'est juste une commodité qui permet
de travailler avec une adresse de base invariable et de faire varier
l'endroit à partir duquel on transfère les données. C'est bien sûr vous
même qui décidez de sa signification et de la pertinence de son
utilisation. Donc c'est vous qui savez pourquoi vous utilisez un offset
de 10 :-) .
En Execution "normale" sans le debuggeur, aucune
anomalie (de façade) mais ce n'est pas rassurant..
C'est le signe caractéristique d'un pointeur ou d'une adresse invalide
ou d'un écrasement de zone mémoire. En mode debug, certains contrôles
sont réalisés par VS. En particulier, les allocations mémoires sont
supervisées et gérées par un code différent (un allocateur mémoire
différent), ce qui permet de détecter les anomalies. En mode release ou
en dehors du débogueur, ce contrôle n'existe pas.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Que fait le DDECreateDataHandle, en particulier l'offset de 10 ?
L'objectif du DDE est d'échanger des données entre processus. Or sous Win32, un pointeur sur un bloc mémoire valide dans un processus n'a aucune signification pour l'autre processus. On ne peut donc échanger des pointeurs entre processus. DdeCreateDataHandle permet donc de dupliquer les données dans un bloc mémoire partagé représenté par le handle et qui sera accessible au client.
Le paramètre offset permet de ne copier les données qu'à partir d'un certain... offset dans le buffer. C'est juste une commodité qui permet de travailler avec une adresse de base invariable et de faire varier l'endroit à partir duquel on transfère les données. C'est bien sûr vous même qui décidez de sa signification et de la pertinence de son utilisation. Donc c'est vous qui savez pourquoi vous utilisez un offset de 10 :-) .
En Execution "normale" sans le debuggeur, aucune anomalie (de façade) mais ce n'est pas rassurant..
C'est le signe caractéristique d'un pointeur ou d'une adresse invalide ou d'un écrasement de zone mémoire. En mode debug, certains contrôles sont réalisés par VS. En particulier, les allocations mémoires sont supervisées et gérées par un code différent (un allocateur mémoire différent), ce qui permet de détecter les anomalies. En mode release ou en dehors du débogueur, ce contrôle n'existe pas.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
