_Michel_

Salut, Ce n'est pas la faute des templates... C'est plutôt un problème de base. Tu inclues un fichier entête maillon.h dans client.cc or rien ne relie maillon.h à maillon.cc. C'est maillon.cc qu'il faut inclure. Il inclura lui-même son entête. C'est ainsi que les choses se passent normalement.

Tout bien réfléchi, il y a une erreur dans ton code. Ce n'est pas supposé produire l'erreur que tu constates mais... Il ne faut pas créer l'objet bdd = new TMySQL(); à chaque clic sur le bouton 1. Sinon tu vas créer des objets à chaque clic et perdre les adresses des précédents. Crée une bonne fois pour toute cet objet dans le constructeur de la fenêtre et détruit le par delete dans un événement tel que OnClose ou OnDestroy. Sinon on peut imaginer un bug dans la dll. Essaie de placer les variables : AnsiString requete, donnee; int reponse; unsigned int i,j; unsigned int nb_champs, nb_enregistrements; comme membres de la fenêtre Form1 (fichier .h correspondant) ou bien comme variables globales (à côté de bdd). De la sorte, elles ne seront plus détruites à la fin de button3Clic().

Je ne vois pas d'erreur dans ton code. J'imagine que cela vient d'une utilisation incorrecte des fonctions de cette dll ou simplement d'un bug dans celle-ci. Mais Kewlcat a raison. Place un point d'arrêt au début de void __fastcall TForm1::Button3Click(TObject *Sender) puis exécute pas à pas pour voir quand se produit l'erreur. Tu auras peut être plus de précisions sur la source du problème.

En fait, en copiant ton code, j'ai fait une petite erreur. Les Text des editbox sont des AnsiString, il n'y a pas besoin d'utiliser c_str(). Ceci dit, cela ne change rien au bon fonctionnement du code. Sinon, je suis parti sur le principe que la fonction ouvrirConnexion() prend des char* comme paramètres. Il faudrait avoir son protype. As tu essayé de passer directement les paramètres sans mettre .c_str() ? c_str() ne fait pas à proprement parler de conversion, il se contente de fournir un pointeur de type char* sur le contenu de l'AnsiString.

Salut, Le problème est effectivement là : Ceci créée des pointeurs mais ne réserve pas la mémoire nécessaire pour stocker les contenus de ces variables. Tu es en C++ builder, autant prendre des AnsiString et ne convertir que lors de l'appel de la fonction. Evidemment, tu peux faire encore plus simple en passant directement les Text.c_str() des cases concernées.

Salut, Il s'agit d'une erreur de contrôleur disque. Des infos et idées ici : http://www.eventid.net/display.asp?eventid...ce=Disk&phase=1

Résultat des tests : Il s'agit d'un programme avec 3 TImage, lancé sous C++ Builder. Une seule image est utilisée, il s'agit d'un JPEG de 701 Ko (1632x1232). Image chargée manuellement dans les 3 Timage : 28 184 Ko utilisé Une seule image chargée, les autres vides : 13 548 Ko utilisé. Une image chargée, Assign() pour les deux autres : 25 396 Ko utilisé Une image chargée, PartTImage pour les deux autres : 13 564 Ko utilisé Globalement les choses se passent bien comme je l'imaginais. Assign() fait bien une copie avec amputation de la mémoire. Il semble que ce soit toutefois un peu plus avantageux que le chargement séparé des trois images (pour des raisons que j'ignore). PartTImage ne consomme pratiquement rien de plus que la seule image chargée.

Normalement Assign fait une copie de l'objet donc c'est normal qu'il n'y ait aucun problème d'effacements multiples. Là où je ne comprends pas, c'est que ça devrait consommer de la mémoire. Je ferais l'essai quand je reviendrais sous windows.

Bonjour, J'ai toujours été effaré de la réaction de certains internautes, ici comme ailleurs. Les gens s'approprient un espace et jugent dès lors qu'il doit être modifié à leur bon vouloir. Ils se sentent investi de la mission quasi divine de rétablir la liberté d'expression. Pourtant les choses sont simples. En général, un forum n'est pas un service public. C'est un endroit mis à disposition de la communauté par une personne ou une société privée. La seule personne qui décide est le propriètaire (administrateur) du forum. Si demain, il juge que le mot "potiron" ne doit plus être prononcé sur son forum, il faudra respecter cette règle aussi absurde soit-elle. On s'inscrit en acceptant ces règles. Si elles ne conviennent pas, on peut partir. Il y a de multiples forums sur le net. Certains ne parlent que de P2P, d'autres de warez, crack et autres activités illégales. En dernier recours, si aucun forum ne convient, on peut se créer le sien. C'est très facile maintenant et ça ne coûte rien ou presque rien. Je ne veux pas dire non plus qu'il est interdit de critiquer les règles établies mais il convient de le faire avec diplomatie et surtout éviter d'exiger quoi que ce soit. L'administrateur délègue une partie de ses pouvoirs aux modérateurs. Ils sont chargés de faire respecter la charte et bien évidemment on retrouve une dimension arbitraire à leurs décisions. On peut désaprouver certains choix, pour autant, il faut les respecter. Là également on peut critiquer mais toujours avec diplomatie. Les gens ne se rendent pas compte c'est que ce n'est pas une fonction facile. Toujours en proie au doute, critiqué vertement par le membre qui trouve sa sanction injuste, un modérateur est toujours en équilibre entre le strict respect de la charte (ou du moins de l'interprétation qu'il en fait) et sa compréhension de la démarche fautive du membre. Si l'on est en total désaccord avec un ou plusieurs modérateurs, il convient d'en tirer les conclusions qui s'imposent, c'est à dire par exemple de partir. Mais, sans doute, suis-je docile et n'ai-je pas ni la connaissance ni la générosité pour aider... Désolé.

.h #include <map> class PartTImage { typedef std::map<TImage*,TPicture*> MTIP; typedef MTIP::iterator I_MTIP; public: PartTImage(); // Constructeur par défaut PartTImage(TImage*); // Constructeur en spécifiant le TImage source ~PartTImage(); bool __fastcall Partage(TImage* dest); // Partage avec le dernier TImage source bool __fastcall Partage(TImage* source, TImage* dest); // Partage en redéfinissant le TImage source inline TImage* Source() { return pTISource; }; // Retourne le TImage* source actuel bool __fastcall EstPartage(TImage*); // Le TImage fait-il partie des TImage partagés ? bool __fastcall Departage(TImage*); // Enlève le partage sur un TImage private: inline I_MTIP Trouve(TImage* pti) { return mPart.find(pti); }; void __fastcall Separe(I_MTIP); TImage* pTISource; MTIP mPart; }; .cpp PartTImage::PartTImage() { pTISource = NULL; } PartTImage::PartTImage(TImage* pti) { pTISource = pti; } PartTImage::~PartTImage() { for (I_MTIP it = mPart.begin(); it != mPart.end(); it++) Separe(it); } bool __fastcall PartTImage::Partage(TImage* pTIS, TImage* pTID) { pTISource = pTIS; return Partage(pTID); } bool __fastcall PartTImage::Partage(TImage* pTID) { if (!pTISource) return false; if (!pTID) return false; mPart[pTID] = pTID->Picture; TPicture** ppTP = &(pTID->Picture); *ppTP = pTISource->Picture; return true; } bool __fastcall PartTImage::EstPartage(TImage* pti) { I_MTIP it = Trouve(pti); return (it != mPart.end()); } bool __fastcall PartTImage::Departage(TImage* pti) { I_MTIP it = Trouve(pti); if (it == mPart.end()) return false; Separe(it); mPart.erase(it); return true; } void __fastcall PartTImage::Separe(I_MTIP it) { TPicture** ppTP = &(it->first->Picture); *ppTP = it->second; } Pour l'utiliser il suffit d'instancier un objet PartTImage (avec new), soit en spécifiant le TImage source (qui contient l'image) soit sans le spécifier. Ensuite l'appel aux fonctions Partage() permet de partager l'image : soit en spécifiant le TImage source en premier paramètre et le TImage qui va recevoir l'image en second paramètre ou bien on ne spécifie que le Timage qui doit recevoir l'image. Dans ce cas, le TImage source utilisé sera le dernier spécifié. pPTI = new PartTImage(); pPTI->Partage(Image1, Image2); // Utilise Image1 comme source pPTI->Partage(Image3); // Utilise Image1 comme source pPTI->Partage(Image4, Image5); // Utilise Image4 comme source pPTI->Partage(Image6); // Utilise Image4 comme source Etant entendu que pPTI est déclaré comme membre la fenêtre (Form1) en tant que PartTImage* et qu'il faut faire "delete pPTI;" à la fin du programme (OnDestroy).

Alors pour répondre à ta question, en effet c'est du C++ donc pas de ramasse-miettes. Toutefois la classe TImage hérite de TComponent qui a entre autres caractéristiques que les objets en dérivant sont automatiquement effacés à la fin du programme sans que le programmeur utilise delete. TImage contient comme donnée membre Picture qui est un TPicture*. TPicture a notamment en charge de stocker en mémoire l'image à afficher. Si plusieurs TImage doivent afficher la même image, pour économiser de la mémoire, on peut s'arranger pour que les membres Picture de tous les TImages concernés pointent vers le même objet TPicture (par écriture directe de la zone contenant Picture de chaque Timage). Le problème c'est que si on laisse le programme se finir en l'état, lors de la destruction des TImage, l'objet Picture qui est en fait le même pour plusieurs TImage va être effacé plusieurs fois de suite (une fois par TImage). Ce qui conduit inévitablement à une fin de programme pas très glorieuse. La solution de facilité consiste à placer ces pointeurs à NULL de façon à ce que delete soit sans effet (puisque delete NULL ne produit aucune erreur). Là où ce n'est pas très rigoureux, c'est que les objets Picture initiaux des TImage modifiés ne sont pas effacés, eux (leur adresse est perdue avec le code que j'ai donné). En pratique cela n'a aucune importance puisque le programme se fini à ce moment là. La mémoire est donc récupérée de toute façon. Je vais poster une classe qui fait tout cela rationellement en bon C++, et sans perdre les TPicture* substitués.

Je pense que tu as dû en nullifier trop ou pas assez (il faut laisser le pointeur original valide). Je ne vois d'autres problèmes liés à l'usage de cette technique. Je n'aurais pas le temps de m'y pencher avant ce week-end. Si d'ici là tu n'as pas résolu ce problème, j'écrirais une classe toute simple qui fera la dupplication des Picture entre les TImage et qui se chargera de la nullification des pointeurs de façon automatique.

C'est exactement ce que tu as codé. La dernière image chargée est affichée par tous les TImage. Si tu veux afficher 12 images différentes, cette solution ne fonctionnera pas. Explique exactement ce que tu veux faire.

L'un de tes problèmes, si j'ai bien compris, c'est que tu veux utiliser plusieurs TImage pour afficher la même image simultanément mais avec des dimensions différentes. La méthode que j'indique permet de disposer de plusieurs TImage avec la même image mais en partageant la zone où l'image est stockée, l'image n'est chargée qu'une seule fois. Pour chaque TImage, tu peux néanmoins préciser les dimensions d'affichage que tu veux. Si tu charges plusieurs fois la même image dans des TImage différents, chacun d'entre eux utilise sa propre zone mémoire, ce qui ampute à chaque fois la mémoire vive. Si ce n'est pas ce que tu veux faire, tu devrais peut être expliquer ce que doit faire cette partie de ton programme. Par contre, je ne pense pas qu'il y ait de méthode simple et surtout universelle pour que la mémoire utilisée pour afficher une miniature soit significativement réduite (par rapport à l'affichage de l'image en taille réelle).

Salut, Sujet intéressant. J'ai une solution mais elle est barbare. Toutefois, je pense qu'il est possible de la rendre acceptable du point de vue objet si tu en fais une classe bien étudiée. L'idée de base est de charger l'image dans un seul TImage puis de copier le pointeur TPicture* Picture dans les autres TImage devant afficher la même image. Ce qui est très facile à faire si on ne pense que C : int v1 = (int) Image1->Picture; int* v2 = (int*) &(Image2->Picture); *v2 = v1; Ici le TImage* Image2 affichera la même image que le TImage* Image1. Reste le problème des suppressions d'objets à la fin du programme. Tel quel, à la fermeture du programme, une exception est générée. Ceci en raison de l'objet commun Picture qui va être effacé deux fois, une fois pour Image1 et une autre pour Image2. La parade consiste à placer les pointeurs contenant l'image dupliqué à NULL juste avant la fin du programme. Dans l'événement OnDestroy de la fenêtre par exemple : *v2 = NULL; Bien évidemment, une fois le principe acquis, il est préférable d'en faire un objet de duplication qui mémorise tout seul les pointeurs Picture dupliqués et les "nullifie" lors de sa destruction.

Salut, Color est la meilleure solution. Pour préciser un peu le reste, il y a sous windows (de type NT) deux types de ligne de commande. La ligne de commande de type console win32 (cmd.exe) et le DOS "véritable" lancé par command.com. Seul ce dernier prend en compte les commandes des fichiers config.nt et autoexec.nt; Or lorsque tu invoques Shell, c'est cmd.exe qui est lancé. Pour faire marcher ton histoire, en plus de modifier config.nt (ajouter la ligne "device=%SystemRoot%\system32\ansi.sys"), il faudrait utiliser : RetVal = Shell("command /c E:\sXPArtBa.bat",1);

Hooker RegGetValue() par exemple serait bien plus efficace. Des logiciels aussi répandus que msconfig, regedit et Hijackthis seraient neutralisés. Commence par faire ton moniteur de clées. Quand il sera fonctionnel, tu auras tout le temps de t'interroger sur le hooking. Je ne te cache pas que c'est d'un autre ordre de grandeur en complexité en raison, notamment, de toutes les méthodes de hooking qui existent. http://www.codeproject.com/system/hooksys.asp

C'est normal je me suis vautré, c'est WaitForMultipleObjects. Désolé. http://msdn.microsoft.com/library/default....ipleobjects.asp

Salut, Il te faut utiliser la fonction RegNotifyChangeKeyValue (API windows): http://msdn.microsoft.com/library/default....ngekeyvalue.asp Il faut indiquer que la notification doit être asynchrone avec le paramètre fAsynchronous = TRUE. Il faut également créer un Event par clée surveillée (API windows CreateEvent) et donc appeller RegNotifyChangeKeyValue pour chaque clée avec un Event différent. Ensuite, tu lances un thread qui va surveiller le changement d'état des events que tu as utilisé. En employant la fonction WaitForMultipleEvents (API windows), tu peux surveiller plusieurs clées (toutes) avec un seul thread. Charge au thread, lorsqu'un Event passe à l'état signalé, de retrouver quelle clée a été modifiée en les lisant et en les comparant aux dernières enregistrées par le programme (code que tu as déjà fait). C'est certes pas super facile à mettre en place si tu n'es pas habitué aux traffics divers et variés de l'API windows, par contre c'est la manière la plus rationelle et la moins coûteuse en temps machine.

Salut, Un peu tard mais tu as le WMI qui prend ça en charge. Il est accessible par VB via un objet de type COM (syntaxe identique à vbs je pense). http://www.microsoft.com/technet/scriptcen...ng/default.mspx

Peut être que le précédent faisait la translation d'adresse ip Lan -> ip Wan dans le contenu de la connexion sur TCP 21 (substituait 192.168.1.253 par ton ip publique dans les arguments de la commande PORT).

Salut, Le soucis est là : Peut être es tu derrière un routeur ou une passerelle ? Ton client envoie 192.168.1.253 comme adresse ip sur laquelle il veut recevoir les données. Il s'agit probablement de l'adresse de ta machine sur le réseau local. Dans les options de ton client FTP, coche le mode passif. Ca devrait mieux se passer.

Alors c'est vraiment un problème de chemin. Soit que path n'est pas prise en compte soit qu'elle est incorrecte. Le truc bizarre c'est que tu obtiennes des chemins avec %SystemRoot% dedans. Sur deux PC différents équipés de XP, j'ai l'équivalence de %SystemRoot% mais en dur : PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; Essaie de taper path = %SystemRoot%\system32. Et si ça ne marche pas, regarde ce que contient %SystemRoot%. Eventuellement entrer son équivalent en dur, par exemple path = c:\windows\system32.

Salut, nul est un nom réservé pour un périphérique particulier de windows. Aucun fichier ne peut avoir ce nom... enfin, en théorie apparemment. Cela peut être assimilé à une erreur du système de fichiers. Essaie de faire une vérification du disque avec correction automatique des erreurs (propriétés du lecteur, outils,... ou bien chkdsk /f en ligne de commande).

Salut, Tu parles de la variable path qui est correcte. Tu obtiens son contenu comment ? En tapant path dans l'invite de commandes ? Si non, regarde ce qu'elle retourne. Autre test, tu peux te placer dans le répertoire contenant ping.exe et essayer à partir de là. Pour ce qui est des commandes cd et dir, ce sont des commandes dites internes qui sont contenues dans l'exécutable de cmd.exe. Il n'y a donc pas de fichier à aller chercher comme pour ping.exe.