Suppression de chaînes dans un fichier

Si, cela a changé quelque chose, j'ai du contenu qui s'affiche dans le fichier contenufichier.txt, des lettres une par une ... Par contre, j'ai encore le message " Le fichier n'a pas pu être ouvert" qui s'affiche, c'est parce que la boucle n'a pas le temps de se faire non ?

Le fichier n'a pas pu être ouvert" qui s'affiche, c'est parce que la boucle n'a pas le temps de se faire non ?

Non

l'erreur est potentiellement du au fait que le "fd.cFileName" contient uniquement le nom du fichier, pour l'ouvrir, il faut avoir le chemin absolu non ?

Oui

De plus, dans ton code, tu ne fermes toujours pas avec fclose() après t'être assuré que le fichier est bien ouvert que ce soit pour la lecture ou l'écriture.

La question se pose aussi de ce que tu veux vraiment faire et pourquoi, et où tu veux créer un fichier "contenufichier.txt". Là tu en crées un seul, qui sera écrasé à chaque fois.

Si ce code est temporaire (vu ton objectif) et que tu veux juste vérifier que tu accèdes bien au contenu du fichier, tu pourrais utiliser le handle du fichier en écriture où tu écris déjà tes messages de débogage au lieu d'utiliser printf

Cela donnerait quelque chose comme cela :

void recursively_list_files(FILE* fichier, char * dir) {
    HANDLE hFind3;
    WIN32_FIND_DATA fd;
    char path[MAX_PATH + 1];
    FILE * fichier2 = NULL;
    int caractereActuel = 0;

    sprintf(path, "%s\\*", dir);

    fprintf(fichier, "---- dans le repertoire %s ----\n\n", dir);

    if ((hFind3 = FindFirstFile(path, &fd)) == INVALID_HANDLE_VALUE) {
        fprintf(fichier, "Erreur FindFirstFIle sur %s\n", path);
        exit(1);
    }

    while(1) {
        if ((strcmp(".", fd.cFileName) !=0) && (strcmp("..", fd.cFileName) != 0)) {
            sprintf(path, "%s\\%s", dir, fd.cFileName);
            if (fd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
                /* c'est un dossier */
                recursively_list_files(fichier, path);
            } else {
                /* c'est un fichier */
                fprintf(fichier, "fichier : %s\n", fd.cFileName);
                fichier2 =fopen(path,"r");
                if (fichier2 == NULL) {
                    MessageBox(hwnd, "Le fichier n'a pas pu être ouvert", "Erreur", MB_OK);
                    fprintf(fichier, "Erreur impossible d'ouvrir %s\n", path);
                    exit(1);
                } else {
                    /* fichier ouvert en lecture - inspection du contenu */
                    do {
                        caractereActuel = fgetc(fichier2); //On lit le caractère
                        fprintf(fichier, "Contenu : %c\n", caractereActuel); //on l'affiche
                    } while (caractereActuel != EOF);
                    fclose(fichier2);
                }
            }
        }
        if (!FindNextFile(hFind3, &fd))
            break;
    }

    if (GetLastError() != ERROR_NO_MORE_FILES) {
        printf("Erreur FindNextFile - dans %s\n", path);
        fprintf(fichier, "Erreur FindNextFile - dans %s\n", path);
        exit(1);
    }
    if (FindClose(hFind3) == FALSE) {
        fprintf(fichier, "Erreur FindClose\n");
        exit(1);
    }
}

(code non testé, je ne suis pas sous Windows)

Avec la fonction appelante gérant l'ouverture en écriture, le passage du pointeur sur FILE fichier, et la fermeture, comme précédemment.

Je n'ai pas mis de fclose() avant les exit(), car la fermeture du programme opère normalement un flush et fermeture, mais on pourrait le faire.

Je crois aussi que tu te casses la tête en t'ajoutant des problèmes. Je ne connais pas bien VS, mais dans des posts comme celui-ci, tu trouves différentes solutions pour afficher des messages de débogage le temps de la mise au point de celui-ci :

https://stackoverflow.com/questions/3009042/how-to-view-printf-output-in-a-win32-application-on-visual-studio-2010

avec la solution proposée par Hans Passant tu peux disposer d'une console et y envoyer tes printf()


You'll need a console window. By far the easiest way to get one is to change a linker option: Project + Properties, Linker, System, SubSystem = Console. Add a main() method:

int main(){
return _tWinMain(GetModuleHandle(NULL), NULL, GetCommandLine(), SW_SHOW);
}

(non testé)

Il y a d'autres solutions proposées sur SO, dont l'envoi des messages dans le "output window" de VS.

En utilisant l'une de ces solutions, tu peux afficher des messages utiles au débogage de ton programme en cours de développement autrement qu'en affichant des boites de dialogue ou en écrivant dans un fichier.

Salut Dal, merci pour ta réponse.

Suite à la conversation avec Phil, j'ai créé une autre fonction, afin que mon code soit plus propre.
La voici :

int AnalyseFichier() 

{
 FILE* fichier2 = NULL;
 FILE* fichier3 = NULL;
 int caractereActuel=0;
  
//on ouvre le fichier contenant les chemins absolu de tous les fichiers

 fichier2 =fopen("C:\\Users\\cTelnaz\\Documents\\Visual Studio 2010\\Projects\\Projet-c\\Projet-c\\donnees.txt","r");
 fichier3 =fopen("contenufichier.txt","w+");

  if (fichier2 == NULL)
  {
   MessageBox(NULL, "Le fichier n'a pas pu être ouvert", "Erreur", MB_ICONWARNING | MB_OK);
    exit(1);

  }
  else     
  {
    do 
        
    {
     caractereActuel = fgetc(fichier2);

     if (fichier3 == NULL)
     {
       MessageBox(NULL, "Le fichier n'a pas pu être ouvert en écriture", "Erreur", MB_ICONWARNING | MB_OK);
       exit(1);
     }

     else 

     {
      //Recherche de la chaîne comprise dans les balises 
      //- > pour l'instant test avec le caractère "y"
 
      if (caractereActuel == 'y')
       
      {
       fprintf(fichier3, "Contenu : %c\n", caractereActuel);
      }
      
      else { MessageBox(NULL, "Pas de code dans les balises", "Erreur", MB_ICONWARNING | MB_OK); }   
     }
    } while (caractereActuel != EOF);
  }
 fclose(fichier3);
 fclose(fichier2);
}

J'obtiens bien mon fichier avec contenu : y.
Par contre, je suis toujours dans une boucle et donc le message "Pas de code ..." s'affiche à chaque fois.

Sinon, pour la console, j'avais bien pensé à faire des recherches, d'ailleurs je connaissais la conversation de ton lien. Malheureusement rien n'a marché, peut-être à cause de compatibilité de version je ne sais pas, je n'ai pas voulu trop perdre de temps là-dessus ... Même si effectivement, c'est un peu agaçant de ne pas pouvoir utiliser de printf.

Après avoir réussi cela, je pourrais m'attaquer à la suppression de caractères ...(j'ai peur)

Remarque, c'est normal vu que fgetc analyse caractère par caractère ...

il y a quoi dans donnees.txt ?

s'il y a la liste des path vers les fichiers :

• tu ne recherches pas dans le contenu des fichiers, mais juste dans le contenu de donnees.txt
• tu te compliques encore la vie, car tu avais déjà ces informations (les path vers les fichiers) dans la fonction récursive

Tu peux faire une fonction de traitement, mais à ce moment, autant l'appeler directement lorsque tu trouves le fichier, non ?

Ensuite, pour vérifier la présence de "<A>" ou "</A>" qui sont des successions de caractères.

C'est possible de le faire avec fgetc mais ce n'est pas le plus efficace, car les appels système seront nombreux (et sont lents).

Si tu utilises fgets() tu auras à chaque appel une ligne du fichier texte, mais rien ne te garantit que le contenu de la balise n'est pas à cheval sur plusieurs lignes, ni même que la balise elle-même ne soit pas à cheval sur plusieurs lignes. Dans un autre ordre d'idées : ta balise peut aussi être "< A>" ou "<a >" ou "< A >" etc., et, peut-être que ton programme doit les considérer comme valides. En tout cas, tu devrais te poser la question de savoir si un strstr() sur une balise "<A>" suffit.

Tu peux alternativement lire tout le fichier et le stocker en mémoire sous la forme d'une chaîne C dans laquelle se trouvent toutes les lignes du fichier et ensuite traiter le contenu de la chaîne.

J'imagine que tu fais ce travail dans le cadre d'un devoir scolaire.

Si c'est le cas, tu dois réfléchir à ton algorithme.

Si ce n'est pas le cas, il y a des moyens plus habituels de faire ce genre de travail avec des regex POSIX (voir la page de manuel

man 3 regex

) ou avec la bibliothèque C PRCE http://www.pcre.org/. Peut-être que Microsoft a un moteur de regex aussi dans son API. Tu pourrais chercher aussi de ce côté.

Dans donnees.txt, il y a effectivement les path de tous les fichiers, c'est pour cela que je me sers de lui pour lire ligne par ligne, et ainsi ouvrir les fichiers via ces lignes.

Au niveau des balises, chaque balise doit être clairement écrite, <A>, de plus, une balise est situé sur une ligne où il n'y a aucun autre caractère. C'est pour cela que j'ai pensais que strstr suffirait.

Au niveau du travail, je suis apprenti dans une entreprise et travail sur un projet assez lourd. Cette partie du projet n'est pas l'objectif, mais permet une amélioration au niveau dialogue informatique. C'est pour cela que cette activité ne rentre pas dans mes compétences de programmation, je n'avais jamais codé en C.

Je te remercie donc encore pour ton aide

OK, peux-tu donner un exemple de fichier texte avec des balises et le résultat que tu veux obtenir une fois le traitement effectué ?

Vu la confidentialité, je vais continuer d'appeler ces balises <A>, </A> et <B>, </B> par exemple.

Tout simplement, le fichier se présente comme ceci :

Début du code : 

code code code code 
code code code code code code code code 
code code code code code 

<A>

code code code code code code code code 
code code code code code code code code 

</A>

code code code code code code code code 
code code code code code code code code code code code code 

<B>

code code code code code code code code 

</B> 

Plusieurs fichiers se présente comme ceci, dont certains n'ont même pas de balises ...

L'objectif est que, par exemple, si j'appuie sur le bouton A (cette condition est le "if" dans le main.c), je veux supprimer le code contenu dans les balises <B> </B> (ainsi que les caractères <B> et </B>, si impossible, ce ne sera pas grave). Ainsi, j'aurais donc les fichiers contenant uniquement le code de base (sans les balises) et le code compris dans les balises <A> et </A>.

D'accord, je comprends mieux ...

Je m'excuse pour le code précédemment posté, l'indentation s'est mal copiée ...

J'ai donc créé un autre projet sur VS pour tester la fonction, après compilation, aucune erreur. Par contre, lors de l’exécution, j'ai l'erreur : Debug Assertion Failed !

La ligne concernée par l'erreur est la 39 sur le code posté ci-dessous.

void supprimer_balise(char * pathfich, char * balise_debut, char * balise_fin)

{

	char st[255];
    int dans_balise =0;
	FILE* fichier3 = NULL;
	FILE* file = NULL;
	FILE* fichnew = fopen("fichnew.txt", "w");

	int is_balise_debut = (strcmp(st, balise_debut) ==0)? 1 :0;
	int is_balise_fin = (strcmp(st, balise_fin) ==0)? 1 :0;


	//On ouvre le fichier correspondant au chemin absolu (de la ligne trouvée)

	fichier3 = fopen(pathfich,"r");

	//on cherche les lignes en boucle, du fichier conerné
	// on mets le résultat dans la variable st

	fgets(st, sizeof st, fichier3);


	//Ouverture d'un fichier en écriture

	file = fopen("fichier.blk.new", "w");


	do {	

			if (!is_balise_debut && !dans_balise)

			
				fprintf(fichnew, "%s", st);
			

			else if (is_balise_debut)
		
			
				dans_balise = 1;
			
				

			else if (is_balise_fin)
		
			
				dans_balise =0;
			 							

		} while (fgetc(fichier3) != EOF);

					//on ferme les fichiers

					fclose(fichier3);
					fclose(file);

		fclose(fichnew);
}


int main (void) {


	char pathfich[] = "C:\\Users\\cTelnaz\Documents\\test.blk\n";
	supprimer_balise(pathfich, BALISE_A_DEBUT, BALISE_A_FIN);

}

après compilation, aucune erreur. Par contre, lors de l’exécution

Oui, ce n'est parce que le compilateur ne va rien te signaler que tout va bien

• ligne 19, il y a toutes les chances que ton fopen en lecture échoue sur pathfich parce que celui-i se termine par \n (comme le ferait une ligne récupérée par fgets de ton fichier de liste de fichiers). Comme tu ne testes pas le retour de fopen pour vérifier l'ouverture, ... (tu utilises un pointeur NULL, etc.)

tu as donc oublié l'étape suivante que je t'indiquais :

    /*
        0. retirer le retour à la ligne de pathfich, s'il y en a un
     */
    char * nl = strchr(pathfich, '\n');
    if (nl != NULL)
        *nl = '\0';

• ligne 24 tu lis une ligne que tu mets dans ton tableau de char st, mais tu ne le fais pas dans la boucle, donc tu lis seulement une ligne. Au lieu de faite une boucle do / while, fait une boucle while qui exécutera le corps de la boucle que si quelque chose a été récupéré

    while (fgets(st, sizeof st, fichold)) {

note que je préfère appeler le pointeur sur FILE "fichold" plutôt que "fichier3" - c'est plus parlant

• lignes 13 et 14, tu testes la valeur de st avant d'avoir lu dans le fichier. Evidemment, il n'y a rien de bon dans les variables initialisées, et tu dois mettre ces lignes dans la boucle après avoir fait cette lecture
• ligne 10 tu définis

  FILE* file = NULL;

  , puis tu ouvres un fichier en écriture ligne 29

  file = fopen("fichier.blk.new", "w");

  , alors qu'en ligne 11 tu en as déjà ouvert un autre

  FILE* fichnew = fopen("fichnew.txt", "w");

  qui est celui sur lequel tu travailles. Il y en a un de trop, supprime file, puisque tu ne mets rien dedans.
• lignes 57 et 60 tu fais des fclose() sur "fichier3" et "fichnew" (note que si tu l'avais appelé "fichold" plutôt que "fichier3" tu saurais mieux identifier que "file" n'a rien à faire là). C'est mal de faire cela sans avoir au préalable vérifié que dans la séquence d'exécution de ton programme les fichiers ont bien été ouverts. Ce que tu ne fais pas, de nouveau. Fais le pour les deux. Une façon de faire est, si l'ouverture en lecture ou écriture est impossible, d'envoyer un message d'erreur et de fermer le programme avec exit(). Si tu fais cela, tu es sûr que si le programme arrive aux lignes 57 et 60, c'est que l'ouverture des deux flux sur ces fichiers s'est bien passée.
• ton indentation est mieux, mais il y a encore des ratés (lignes 55 à 58) et encore des lignes ou doubles lignes sautées un peu partout. Tu devrais adopter un style et t'y tenir. Le plus classique en C est celui de K&R, les créateurs du langage : https://fr.wikipedia.org/wiki/Style_d%27indentation.

Il y a peut-être d'autres problèmes, car je n'ai pas tenté d'exécuter et déboguer ta fonction.

Déboguer fait partie de la programmation. Pour limiter le nombre de problèmes, tu devrais développer en itérations courtes. A mesure que tu programmes, dès que tu as quelque chose de testable, tu le testes, et tu n'attends pas d'avoir écris une 50aine de lignes pour le faire.

A toi de jouer :-)

En parlant de tests...

En fait, je t'ai détaillé un algorithme que tu peux mettre en oeuvre avec la façon dont tu voulais traiter le problème, mais ce design ne me plaît pas trop, pour plusieurs raisons.

L'une d'elle est qu'il dépend trop, au coeur de son fonctionnement d'éléments externes au programme (les fichiers), ce qui le rend difficile à tester facilement au moyen de tests unitaires.

1.

Alors, au risque de te faire "pêter un câble", si j'étais toi, je jetterais tout le contenu actuel de la fonction, pour que cette fonction

void supprimer_balise(char * pathfich, char * balise_debut, char * balise_fin);

, à la place, appelle les fonctions suivantes :

• une fonction

  char * charger_fichier(char * pathfich);

  qui charge le fichier à traiter dans sa totalité en mémoire et le met dans une chaîne de caractères C dont elle retourne l'adresse, ou NULL si le fichier ne peut être chargé
• une fonction

  char * traiter_retrait_balises(char * contenu, char * balise_debut, char * balise_fin);

  qui contient le coeur de l'algorithme travaillant, cette fois, en mémoire et non pas avec des fgets() et fprintf(), qui renvoie l'adresse d'une nouvelle chaîne de caractères C comprenant la totalité du contenu du fichier retraité s'il y a des balises correspondantes dedans, ou NULL s'il n'y en a pas et que le fichier ne doit pas changer
• une fonction

  int remplacer_fichier(char * pathfich, char * contenunew);

  appelée si traiter_retrait_balises() renvoie autre chose que NULL et qui s'occupe d'écrire le contenu nouveau dans un fichier temporaire, d'effacer l'ancien fichier, et de renommer le fichier temporaire, ou le renommer et déplacer (si tu ne l'as pas créé au bon emplacement déjà).

2.

De cette façon, on isole les parties qui font des entrées / sorties, et on dispose d'une fonction traiter_retrait_balises() que l'on peut tester facilement, avec une batterie de tests unitaires que tu peux créer sur les différents types de cas de figure que doit gérer le programme, pour en vérifier le comportement, et que tu pourras rejouer automatiquement. Pour ces tests, il suffira de disposer de jeux de tests avec des chaînes fournies en entrée et des chaînes attendues en sortie, et tu pourras vérifier le comportement attendu en comparant ces chaînes. Si tes tests sont représentatifs des comportements attendus selon les différents cas, ils seront des alliés précieux :

• pour prouver objectivement que ton programme fonctionne selon un comportement attendu
• pour te permettre de faire évoluer ton programme en rajoutant des comportements additionnels (avec de nouveaux tests associés), ou en améliorant le code existant, tout en ayant l'assurance que les comportements précédents continuent de fonctionner (absence de régression)

Tu pourras alors faire ceci :

https://fr.wikipedia.org/wiki/Test_driven_development
avec les bénéfices expliqués dans cette page succincte

3.

Ce découpage présente aussi l'avantage que l'on ne va pas s'amuser à écrire un fichier nouveau, effacer, renommer, remplacer des fichiers si, en fait, il n'y a pas de balise dedans qui corresponde à ce que l'on veux supprimer...

4.

Le fonctionnement sera plus rapide, car il est plus rapide de lire un fichier d'un bloc que de le lire ligne par ligne (au prix d'une utilisation de mémoire vive supérieure).

Les avantages expliqués en 2., 3. et 4. sont non négligeables :-) mais c'est surtout le 2. qui est important.

Je te remercie beaucoup pour le temps que tu donnes pour m'aider.
J'ai compris où tu voulais en venir mais je dois attendre mon retour au travail lundi pour m'y remettre. (Matériel spécifique)

Cependant, je vais relire ce que tu as envoyé pour être sûr de bien comprendre, afin d'être efficace la semaine prochaine.

Bonne soirée Dal :)

Oui vois le lien Wikipedia que j'ai posté plus haut sur cette méthodologie.

contenunew = (char*)malloc(sizeof(char)* nbrcontenunew);

non, c'est

contenunew = (char*)malloc(nbrcontenunew + 1);

car tu as besoin d'un byte additionnel pour le '\0' terminateur.

Note qu'il n'est pas faux de multiplier cela par

sizeof(char)

, mais cela ne sert à rien pour le type

char

car la norme du C garantit que ce type a une taille de un byte. Tu multiplies par 1 donc... autant ne pas écrire cela (ce ne sera pas le cas avec d'autres types de

char

, bien sûr, où le sizeof a un sens, par exemple un type

int

, qui peut occuper 4 à 8 bytes, mais là c'est des

char

).

En ce qui concerne le reste de ton code, je ne sais pas où en est ta fonction, mais dans ce que tu as posté là : https://forums.commentcamarche.net/forum/affich-37193175-suppression-de-chaines-dans-un-fichier#48 je vois que :

• tu ne testes pas si la chaîne "contenu" passée est vide : si elle est vide, tu peux faire un

  return NULL;

  tout de suite en début de fonction et ton test 1. passera parce que tu auras implémenté ce comportement
• ligne 22 tu fais

  return contenunew;

  après avoir ajouté une ligne ... pourquoi cela ? Ce n'est du tout l'algo que j'ai montré plus haut lorsqu'on s'occupait d'ajouter une ligne à un fichier
• ligne 50 tu fais

  free(contenunew);

  alors que ... ta fonction est sensée renvoyer cette chaîne ... !

fais un peu attention stp

Effectivement pour le "free" cela était un peu bête, j'ai donc essayé de corriger mes erreurs.

Voici mon code plus propre :

code :

char* traiter_retrait_balises(char * contenu, char * balise_debut, char * balise_fin)

{ 
 char* contenunew;
  
 //Si le contenu est vide, on retourne NULL

 while (contenu != NULL) 
 
 {
  int dans_balise =0;


  //On découpe la chaîne avec les caractères de séparation \r\n

  char * ligne = strtok(contenu, "\r\n");
  


  //On compte le nombre de caractère de la chaîne

  int nbrcontenunew = strlen(ligne);

  //On alloue la mémoire

  contenunew =(char *)malloc(nbrcontenunew + 1);

  while (ligne != NULL) 
  
  {
   int is_balise_debut = (strcmp(ligne, balise_debut) ==0)? 1 :0;
         int is_balise_fin = (strcmp(ligne, balise_fin) ==0)? 1 :0;

   //Si on est pas dans la balise et que "ligne" n'est pas une balise de début,
   
   if (!is_balise_debut && !dans_balise)

   {
    //On ajoute la ligne à la chaîne à retourner

    strcat(contenunew, ligne);
   }

   else if (is_balise_debut)
  
   {
    dans_balise = 1;

    return NULL;
   }
    

   else if (is_balise_fin)
  
   {
    dans_balise =0;

    return NULL;
   }      

   /*on demande à strtok() de nous trouver la prochaine ligne 
    et on boucle
    */

   ligne = strtok(NULL, "\r\n");

  }

  //Dès qu'il n'y a plus de lignes, on retourne le nouveau contenu

  return contenunew;
 }

 return NULL;
}

Ce code est juste pour montrer mon état d'avancement, j'ai ajouté un fprintf juste après le strtok, cela m'affiche des centaines de lignes avec : "Ceci est un texte". Je reprends demain pour essayer d'y remédier.

Tu as mis tout le code de la fonction dans une boucle

while (contenu != NULL)

qui se répète indéfiniment.

si c'est une tentative de faire ceci :

"tu ne testes pas si la chaîne "contenu" passée est vide : si elle est vide, tu peux faire un return NULL; tout de suite en début de fonction et ton test 1. passera parce que tu auras implémenté ce comportement"

• tu ne testes pas si le pointeur sur char pointe vers une chaîne qui est vide, mais tu testes si le pointeur sur char est initialisé avec une adresse mémoire ou pas.
• de façon inexplicable, tu le fais dans une boucle while au lieu d'un simple if

Pour tester si la chaîne "contenu" passée est vide, tu dois accéder au premier élément pointé par l'adresse mémoire contenue à ce pointeur, et si ce premier élément est égal au caractère terminateur de chaîne, c'est que ta chaîne est vide.

Donc, la conditions suivante, en début de ta fonction suffit à satisfaire le test 1 :

 if (contenu[0] == '\0')
     return NULL;

Retire ta boucle while, y compris son accolade fermante (bien sûr) et supprime le

return NULL;

que tu as mis en dernière ligne de la fonction. La dernière ligne de ta fonction doit retourner contenunew lorsqu'elle arrive à la fin de la fonction et que toutes les lignes ont été traitées.

Ensuite, dans ton code, tu arrêtes la fonction en faisant

return NULL;

lorsque la balise de début est trouvée (et tu fais pareil quand la balise de fin est trouvée). De nouveau, ... pourquoi cela ? Ce n'est du tout l'algo que j'ai montré plus haut lorsqu'on s'occupait d'ajouter une ligne à un fichier.

La boucle pilotée par le while sur strtock() doit se poursuivre jusqu'à la fin de la chaîne traitée, pour que tu espères traiter toutes les lignes, non ?

Donc, retire ces deux

return NULL;

.

Edit :
Maintenant que tu postes la fonction complète je vois aussi une autre erreur qui m'avait échappée : tu fais ton malloc sur la longueur de la première ligne récupérée par strtock(), alors que le but est de disposer d'une zone mémoire au moins aussi grande que le contenu passé à la fonction pour dimensionner contenunew...

Donc, bien évidemment, tu dois faire :

  char * contenunew = malloc(strlen(contenu) + 1);
  char * ligne = strtok(contenu, "\r\n");

et pas ce que tu fais...

Tu ne peux pas juste te contenter d'un

strcat(contenunew, ligne);

. Car il te faut ajouter les retours à la ligne. D'ailleurs, à la réflexion, je pense aussi qu'un \n suffirait à la fin de chaque ligne pour le contenunew généré, car Windows s'occupera tout seul de rajouter les \r à l'écriture du fichier texte à la fin de chaque ligne de texte. Le jeu de test devrait être modifié en conséquence (pour le 3ème).

Pour le 2ème test, il a une adaptation à faire de l'algorithme, pour qu'il garde trace du fait que qu'une balise attendue est présente ou pas et renvoyer NULL si elle ne l'est pas. Je te laisse la trouver :-)

Il y a aussi un autre détail à prendre en compte, c'est que strtok() va écraser les retours à la ligne consécutifs. C'est lié au fonctionnement de cette fonction, puisqu'ils sont considérés comme séparant des chaînes.

Comme tu disais dans ta spécification que les lignes vides n'avaient pas d'importance, je comprends que cela n'est pas grave pour toi.

Par contre, c'est à prendre en compte dans les tests.

Donc le 3ème pourrait être :

void test_trb_chaine_avec_une_balise_recherchee(void) {
    char balise_debut[] = "<B>";
    char balise_fin[]   = "</B>";
    char contenu[]      = "Ceci est un texte.\r\nIl comprend une balise recherchée\r\n\r\n<B>\r\nTexte dans B\r\n</B>\r\nC'est terminé";
    char expected[]     = "Ceci est un texte.\nIl comprend une balise recherchée\nC'est terminé\n";
    char * contenunew = traiter_retrait_balises(contenu, balise_debut, balise_fin);
    assert(contenunew != NULL
            && "test_trb_chaine_avec_une_balise_recherchee ne doit pas renvoyer NULL");
    assert(strcmp(expected, contenunew) == 0
            && "test_trb_chaine_avec_une_balise_recherchee doit renvoyer la chaîne attendue");
    free(contenunew);
}

Un handle est de type HWND et ce n'est pas la même chose qu'un id de l'élément de la boite de dialogue, qui est de type int.

Si tu ne connais pas déjà le handle HWND du bouton qui t'intéresse, tu peux le récupérer avec GetDlgItem() en lui passant le handle vers la boite de dialogue qui contient le bouton et l'ID du bouton :

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdlgitem

D'accord, par exemple je rajoute dans

case WM_CTLCOLORBTN 

:

HWND hBtn;

hBtn = GetDlgItem(hBouton2, 4);

/*....*/

Avec hBouton2 la boîte de dialogue du bouton et 4 son ID.

Mais après, j'ai du mal à comprendre comment utiliser cet handle pour créer la condition...

Tu le compares au lParam passé à ton callback dans lequel tu dois avoir ce switch/case et qui traite les messages... selon la doc lorsque le message est de type WM_CTLCOLORBTN, lParam contient le "HWND that specifies the handle to the button".

C'est bien une une fonction du type

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

dans laquelle tu es, non ?

Je ne pense pas que tu aies besoin d'exécuter GetDlgItem là dedans. Tu vas inutilement ralentir le programme et le traitement des événements, alors que, probablement, le handle ne va pas changer et restera le même une fois l'application initialisée. Renseigne toi, et fais des tests :-)

J'ai tenté d'écrire uniquement :

case WM_CTLCOLORBTN :

       if (lParam ==(LPARAM)hBouton2) { return (LRESULT)CreateSolidBrush(bgColor); }
       break;

Ici j'ai bien uniquement le bouton 2 qui est concerné, mais pour ajouter la condition aux autres boutons, je pense que ce n'est pas possible.

Il faudrait potentiellement utiliser WM_DRAWITEM ...