Bon, je vais essayer de donner le plus possible d'éléments parce que mon truc est vraiement bizare (j'en ai marre du 16bits...tout s'y passe bizarement ! )
Alors, en fait j'écrit dans un fichier des lignes, les unes après les autres afin de dessiner un tableau, genre:
___________________________
Libélle | Nombre | Fichier
___________________________
Moi     | 1      | moi.txt
lui     | 2      | lui.txt
etc...
 
et en fait, en mode débug (sous Visual C 1.5, hé oui, pas l'choix) tout se passe bien
Mais en Release, rien ne vas plus, tout se chevauche, des trucs sont écrits à moitié, bref, c le bordel...
 
Qqn voit une explication plausible à ça !?

[edtdd]--Message édité par El_gringo--[/edtdd]

Le code pour écrire les lignes, il ressemble à quoi ?
 
Pour tabuler, on peut mettre des caractères HT (je sais plus la valeur ASCII, 8??) à chaque saut de colonne, mais si le soft qui les lit considère que HT vaut 8 espaces, si une chaîne fait plus de 8 caractères, on passe à la colonne suivante (soit 8+8 caractères => pas joli car décalé).
Les espaces, c'est plus sûr sauf avec police proportionnelle car les espaces sont plus compact que les lettres, W est plus long que I....

Mais la mise en page c pas un problème, j'utilise une chaine formatée:
wsprintf (szBuffer, "%8s|%8d|%5s",libelle, nombre, fichier);
et puis j'écrit ce buffer dans mon fichier par un  
_lwrite (fe, szBuffer, strlen(szBuffer));
Tant dis que g déja ouvert mon fichier.
Mais en fait, apparement, c plutot que c le bordel dans szBuffer(en release seulement, j'insiste bien là dessus !).
char szBuffer[256] est déclaré en global, si g bien compris, szBuffer est donc un pointeur far...le pb peut venir de ça !?

en fait g appris que la mêmoire n'est pas gérée de la même façon en debug que release...c peut être une explication, non !?
Tu te rappel, c moi qui soupconnais il y a 15 jours un pb de débordement mémoire dans une appli 16 bits que je modifiais...c la même !

Est ce que tu as bien fait les #include qu'il faut string.h ...
 
A+

 
  oui, c gentil d'essayer de m'aider, mais heureusement que g pensé à ça...d'ailleur sans ça mon appli fonctionnerai pas du tout !

Bizarre de traiter la mémoire de façon différente... Ca aide pas du tout.
 
Une possibilité :
déclarer char Buff[256]; (256 par exemple) dans le corps du module qui écrit dans le fichier d'où
wsprintf (Buff, "%8s|%8d|%5s",libelle, nombre, fichier);  
 
Une autre est d'utiliser sprintf() qui est pur C (dépend de stdio.h je crois) et qui ressemble beaucoup à wsprintf().
J'ai eu des problèmes avec wsprintf() quand je voulais gérer autre chose que des entiers (float par ex). Ca cafouillait sous Borland C 3.1....

bonnes idées...que j'avais déja eues durant ces 3 derniers jours de galères !
le sprintf fait exactement pareil
mais c bien à se moment là que l'erreur se produit (et non pas lors de l'écriture dans le fichier) j'en suis sûr maintenant.
tu connais pas de fonction genre sprintf qu'on pourrais utiliser a la même fin ?
J'en ai vraiemet marre !
En fait, maintenant, même si je fait ça:
 
char* temp = (char*)malloc (256);
memset (temp, 0, sizeof(temp));
strcpy (temp, "coucou" );
MessageBox (NULL, (LPCSTR)zemp, (LPCSTR) "Test", MB_OK);
 
je vois qu'il y a n'importe quoi dans temp...

J'ai l'impression qu'on a les mêmes façons de debugger !!!
Dans MessageBox(), les (LPCSTR), suis pas certain qu'il soient utiles (nuisibles ?). Les char passent bien chez moi.
 
strcpy() met bien un zéro à la fin de la chaîne, donc initialisation pas indispensable.
 
Le (LPCSTR)zemp, c'est une faute de frappe ?

j'initialise toujours, c plus sûr !
oui, zemp c une faute de frappe qui est pas dans mon prog...
Et ça m'étonne pas que ça passe chez toi, c tout simple ce truc !
Mais ça passe pas dans mon appli... y a donc surement un pb avec les segments de données tu penses pas !? tu vois autre chose possible !?
(sinon, les LPCSTR n'ont pas l'aire nuisible...c pareil sans !)

J'ai des "doutes" des fois sur les LPSTR, LPCSTR et le LPCTSTR du 32 bits (ou analogue ..). Suis pas très doué    
 
Si cette boîte de message est mise plus avant (au niveau exécution) dans le programme avant d'arriver à la préparation de l'écriture dans le fichier, ça fait pareil ? Si non, qq chose cloche "entre les deux". Si oui, problème !...
 
Une fois j'ai eu une feuille de dialogue (16 bits) qui ne voulait plus s'afficher car j'allouais 16 octets dans une chaîne et j'en écrivait 18. Aïe aïe. C'est tellement délicat.
 
Retour dans 30 min, la chimie me réclame.  

ouais, si je le met dans le "initInstance" ça fonctionne...
 
En plus t'as eu une bonne intuition, parce qu'on m'a prévenu que dans cette appli (appli que je retouche, je le rappel !)
c bien possible qu'on dépasse des tableaux (genre mettre 18 octets dans un tableau de 16) un peu partout. bref, ils ont fait ça comme des porcs !
Mais c Im-po-ssible que je corrige ça maintenant, c gros comme truc; même très gros !
Tu vois pas une truc alternatif qui pourrais forcer à réordonner un peu les choses, et me sortir de cette merde !?

Pour "aider", le compilateur, il ne donne pas la taille des datas et du code après compilation (pour voir si "déborde" ).
Sous BC, dans la feuille où sont les noms des fichiers du projet, une fois compilé, on a la taille de chaque module. Ca permet de savoir si on n'a pas trop de code.
 
Y a qu'UN fichier .C(PP) ? Si c'est un gros projet, c'est étonnant !!!
 
C'est le prog 16 bits qui est appelé par un prog 32 bits par un shell avec nom de fichier compressé à la 16 bits, je crois.  
 
Cela semble une galère. Adapter et compléter un prog mal fichu ...
 
Je code en 16 bits (presque) tous les soirs mais je fais attention à pas trop faire de bétises (du moins celles que je vois).

ouais, y a

merde...
 
ouais, y a qu'un seul .C ... d'environ 2000 lignes !
Bonne mémoire, bravo
 
T'as conclusion, en gros, c : "je peux pas grand chose pour toi, c vrai que t dans la merde ! Bonne chance..." c ça !?  g bien compris non ?
merci d'essayer qd même ! surtout que je livre normalement ce truc à un client Mardi prochain...  

Y aurait peut-être moyen (méthode "bourrin" ) de déplacer ton messageBox avec la déclaration de tout à l'heure cran par cran pour voir où ca fonctionne bien. Quand tu passes de "c'est pas bon" à "c'est bon", entre les deux, y a qq chose qui va pas.
 
Mais c'est tellement subtil des fois.
Je suis naïf car amateur pas toujours pas éclairé.
 
A distance, pas facile de faire qq chose.
 
Une chose certaine (Lapalisse), le code du MessageBox, il DOIT fonctionner !!!!

ouais... j'vais tenter ça !
 
parcontre, Lapalisse, qu'es ce qu'il vient faire la dedant !?? :-)

C'était juste pour dire que c'est "évident". Code basique assuré de fonctionner (sauf pb extérieur)..
 
S'il n'y a "que" 2000 lignes, je veux bien y jetter un coup d'oeuil, mais je ne m'y retrouve pas toujours dans mon propre code (38000 lignes), et j'ai du mal à lire celui des autres (sauf Microsoft, exemples anciens, bien structurés)..

Ouais, ça serai pas mal que tu regarde, mais le problème c que cette appli est pas autonaume. Son rôle c'est de repérer le fichiers qui sont dans un répertoire, et d'envoyer à un autre progiciel (progiciel d'archivage), une commande lui indiquant d'archiver ces fichiers. Mais celui là je peux pas te la passer, y doit bien faire ses 50Mo...
du coup, tu pourrais regarder le code, mais pas essayer l'appli. Tu te sentirais de faire ça !?

...quoi que ça te laisse un chance de devenir un héro. Parce que, si t'arriverais à me sortir de cette merde, tu serai bel et bien un héro... ça se rate pas une telle occasion...

Rien n'est garanti. Si c'est très "crad", ça fatigue la tête.
D'ici lundi, ce sera peut-être "résolu" par tes soins... L'union fait la force.
 
mail paul.rmd@caramail.com (fichiers projet/.C/.RC/.DEF/.H spécifiques, ....)
 
J'ai que BC3.1/BC5/VC1.0. J'espère que cela ne fait appel à des trucs trop propriétaire/spéciaux/...
 
Le critère pour l'archivage des fichiers, c'est quoi? Je pense que le problème vient d'ailleurs. Si je peux simuler un traitement, ça permet de tester en "run".
 
 

on va essayer, on verra bien !

YESSSSSSSS !!!!!!!!

C bon, ça marche... j'ai réussi, pas la peine que tu te casses la tête la dessus.  
         
En fait, le fait que je fasse un
 
wsprintf (szbuf, "libelle:%s nombre:%s", varLib, varNb);
 
ça lui plais pas; il faut au préalable que je mette "libelle:%s nombre:%s" dans une chaine, et, ensuite je passe un pointeur vers cette chaine en paramètre de wsprintf.
...qd même, c un belle merde ce 16bits
 
T'as déja essayé le 32bits Carbon14 !?  
 
Allez, merci, Ciao, et à la prochaine...

C'est bien.    
 
Le 32 bits, je m'y frotte quand le 16 est au point. J'écris pour 16 (on a plein de PCs avec Win 3.1 (voir deux avec Win 3.0)) et le même code (avec des #ifdef __FLAT__ #else #endif pour les fonctions qui ont été changées) pour Win95/98/..
 
Pour l'instrumentation, DOS et Win 3.1, c'est bien car l'accès aux cartes est direct. Pas besoin de pilotes spécifiques (qui de plus n'existent pas pour des cartes A/D anciennes).
 
Le seul problème est pour gérer plus de 64k de données d'un coup. Les pointeurs huge sont alors utiles. Ou jongler avec les segments, comme j'avais commencé à faire.
 
J'ai abandonné Wsprintf(), (pb bizarres non résolus) surtout en vue de compiler mes oeuvres un jour pour l'OS du pingouin. Mais je serai alors le seul à les utiliser...

et ... tout ça, tu l'fais pour ... ton plaisir !?
Gratuitement si g bien compris !?

Le plaisir est gratuit    
J'adore rendre service    
 
Ce n'est pas mon métier, je n'ai aucune qualification reconnue dans le domaine.
Quand on n'a pas d'impératifs commerciaux, on peut y mettre le temps qu'il faut. Personne ne va réclamer.
 
NB : pour l'initialisation après malloc() d'hier, quelqu'un avait signalé y a qq temps que calloc() faisait malloc() puis memset(0 ) d'un seul coup...