bonjour, j ai un pb sur le code suivant(imprime le handle et le nom de toutes les fenetres active a l'écran) au niveau des variables char * titre et char * identifiant au moment d imprimer le resultat a l ecran, la variable identifiant est normal mais la variable titre contient la variable identifiant:
328088:Invite de comman32808
au lieu de
328088:Invite de commande - edit testfen.cpp et la meme chose se produit pour tous mes affichages.
selon moi, les 2 tableaux se recouvrent en memoire, car si je modifie identifiant avant titre, c'est identifiant qui contient une partie de titre.
si qq1 peut m'aider.
au fait j utilise free borland C++ compiler 5.5
#include <windows.h>
#include <string>
#include
void main(void) {
int taille=1; //taille du tableau nom de fenetre
char * titre=(char *) malloc(taille); //alloue un tab de 1char pour le nom de la fenetre(non suffissant)
char * identifiant=(char *)malloc(12); //alloue un tableau de 12char pour l identifiant(tjr suffissant)
HWND handle=GetForegroundWindow(); //handle de la fenetre au premier plan(faut bien commenc? qq part!)
UINT direction=GW_HWNDNEXT; //direction pour la recherche du prochain handle => suivant
while ( handle != NULL ) { //tant qu on a pas epuise tout les handle
handle=GetNextWindow(handle,direction); //recup le handle suivant
if (handle != NULL && IsWindowVisible(handle)) { //tant qu'on a un handle
taille=GetWindowTextLength(handle); //taille du texte de la fenetre
if ( GetWindowTextLength(handle)+1>taille ){ //si la taille n est plus suffisante
taille=GetWindowTextLength(handle); //recup la taille du texte
realloc(&titre,taille); //realloue l espace memoire necessaire
}
GetWindowText(handle,titre,taille); //recupe le texte de la fenetre
identifiant=itoa((long)handle,identifiant,10); //convertit le nø du handle en char *
cout << identifiant << ":" << titre << endl; //affiche l identifiant et le titre de la fenetre
}
else if (direction==GW_HWNDNEXT) { //si plus de handle ds la direction 'suivant'
direction=GW_HWNDPREV; //change la direction('precedent')
handle=GetForegroundWindow(); //repart du meme endroit(fenetre au premier plan)
}
}
}
Il ne fait pas de C, il fait du C++, il peut très bien utiliser malloc() et compagnie en C++ mais il doit transtyper en C++ ...
Faut faire gaffe avec realloc()
NewPtr = realloc( OldPtr, NewSize );
si realloc() ne peut pas, pour une raison quelconque, reallouer de l'espace pour OldPtr, il retourne NULL mais ne libère pas l'espace de OldPtr ... Donc, titre = realloc(titre, taille) risque de poser problème un jour ou l'autre ...
Et heu ... juste comme ca, il manque les free() ...
Dernière chose, si tu code en C++, inclus la stl de cette facon:
#include <string>
#include
// etc ...
using namespace std;
// sans .h à string, iostream, list, vector, etc ...
qu'on soit d'accord, soit c'est du c++ (standard) avec la lib standard (mais pas de malloc/free, plutot les allocateurs du c++)
j'ai dis de faire du c car ce code n'a rien de c++ a part iostream.h (qui n'est pas standard) et string qui ne semble pas etre utilisé (sans parler du void main qui ne compile pas en c++), donc a partir de ce code c'est plus simple de faire du bon c que du c++ (on apprend pas stl & co en 5min)
Ce n'est pas mon `genre` de m'obstiner sur ce genre de sujet mais, standard, standard, standard, ... Vous croyez vraiment que _tout_ le monde code `standard` !? Utilise _que_ les `standard` !? `standard` !? standard par ci, standard par la ...
Le fait d'utiliser malloc()/free() ne pose aucun problème, new/delete fait appel à malloc()/free() alors moi j'me dis que si je préfère malloc()/free() à new/delete pourquoi ne pas utiliser directement malloc()/free() ! Le seul _vrai_ problème c'est avec les class/objets en C++ ou new/delete sont utile au niveau des constructeurs/destructeurs ...
Le fait d'inclure iostream.h(avec .h) je crois que c'est seulement parce qu'il ne le savais pas. <string> ... c'est peut-être pour des besoins futurs, qui sait!
De plus, sa compilation ce fait en C++, iostream(avec ou sans .h) & string(sans .h) ne compile pas en C ...
Pourquoi void main(void) ne compilerait pas !? Parce que ce n'est pas standard !? Sans commentaire ...
C'est vrai qu'en C/C++ il est préférable de prendre de _bonne_ habitude dès le départ ... Apprendre correctement les standards(suivant le langage) pour être capable de les utiliser à leurs maximum et de facon correct, etc ...
C'est vrai que le fait de mélanger le C et le C++ n'est peut-être pas très `standard` mais tu peux très bien faire du code très puissant, fiable, structuré, sécuritaire, ... même si tu le fais ...
On dirait que l'on pense _que_ `standard`, certe, c'est très bien mais il ne faut pas devenir parano non plus(faut pas le prendre perso hein) ...
c'est toi qui vois, seul le standard garanti la portabilité du code (void main interdit en c++, sur certains systeme ca ne fonctionnerais pas)
"
C'est vrai que le fait de mélanger le C et le C++ n'est peut-être pas très `standard` mais tu peux très bien faire du code très puissant, fiable, structuré, sécuritaire, ... même si tu le fais ..."
tout a fais d'accord, mais c'est pas ce que je conseillerais a un debutants, sauf si il connais deja le c
mais bon, moi je prefere largement la stl
bon ben effectivement je debute en C++ et j ai jamais fait de C. j ai un compilateur C++ mais pas de doc avec alors j en recup un peu et je fait des essais.
c est vrai q ca donne peut etre des codes un peu bizarre!
en tt cas merci... pour le coup du void main ca compilait tres bien mais maintenant je connai!!
bs dit de ne pas utiliser malloc/free en c++ car pas definition tous les types sont des objets et seuls new/delete et new[]/delete[] construisent/detruisent les objets
