JE fais une interface graphique autour de dll 32 console.
Ces dlls renvoie des messages d'erreurs sur la sortie standard et il faudrait que je récupère ces messages.
 
Est-il possible de rediriger la sortie standard ou il y a-til un moyen de récupérer ces messages dans un buffer que j'enverrais sur une boite de dialogue ?
 
 
REGARDER LE GROS POST DU BAS   MARQUé ICI

[edit]--Message édité par Moustaaki--[/edit]

on n e peut pas, donc .... ARGL

Déja une dll Dos ça n'existe pas (enfin si mais c'est très très très rare), je pense que tu veux parler d'une DLL en mode console ( très différent).
On peut le faire, j'ai déja vu des API qui le permettent. Je pense qu'il faut se plonger dans le guide de référence de Win32 et rechercher les fonctions correspondant au mode console.

vi vi, c'est dll 32 consoles... j'ai dit DOS parceque personne ne répondait et je pensais que ça serait plus compréhensible. Apperement, non, alors, je réctifie : CE SONT DES DLL 32 CONSOLES !
 
pour ce qui est de la doc, j'ai du mal à trouver sur le net...
j'ai pas la doc msdn (mon équipe n'a toujours pas commandé ou reçus visual) et j'ai donc que le net. La doc papier, j'en ai pas non plus ! c assez galère.

oui, on peut rediriger la sortie standard vers un buffer, il suffit de jouer avec les pipes...

La doc papier (elle existe ?) et la doc CDROM sont de toute façon moins complète que le site msdn.microsoft.com ( qui a un très bon moteur de recherche).
 
Concernant ton problème :
http://msdn.microsoft.com/library/ [...] r_8hbn.htm

 
hé...personne réponds à ma question qui est pourtant très très interessante, alors, je suis sympa, je vous propose même un p'tit lien pour y aller      
http://forum.hardware.fr/sqlforum/ [...] ache=cache

voui, ben ça marche po.
je vous montre ce que j'ai fait, j'ai surement fait des grosses conneries vu que je suis une merde en info :
 
// déclaration variable globale :  -----////
// buffer de sortie, permet de rediriger la sortie standard.
char sortieO[512] ;
// buffer pour les erreurs.
char sortieE[512] ;
 
 
//----- Dans le main :  ----///
 if(!(SetStdHandle(STD_OUTPUT_HANDLE, sortieO)))
 {
  MessageBox(NULL,"Echec dans la redirection", "La redirection à échouée", MB_OK | MB_ICONERROR ) ;
 }
 
 if(!(SetStdHandle(STD_ERROR_HANDLE, sortieE)))
 {
  MessageBox(NULL,"Echec dans la redirection", "La redirection à échouée", MB_OK | MB_ICONERROR ) ;
 }
 
// déjà, là, ça marche po : il n'arrive pas à rediriger la sortie, est-ce qu'il faut que je fasse un buffer plus grand ?
 
 
/// --- avant l'appel de la fonction :
sortieO[0] = '\0' ;
sortieE[0] = '\0' ;
 
// juste après l'appel de la fonction :
if(sortieO[0] != '\0')
  MessageBox(NULL, sortieO, "info", MB_OK | MB_ICONINFORMATION | MB_APPLMODAL) ;
if(sortieE[0] != '\0')
  MessageBox(NULL, sortieE, "Erreur", MB_OK | MB_ICONINFORMATION | MB_APPLMODAL) ;
 
 
 
 
 
voilà. Il doit y avoir une connerie au niveau du buffer : faut-il qu'il soit plus gros ? faut-il faire un pointeur dessus ? est-ce que je suis vraiment trop con pour faire de l'info et est ce que je ferais pas mieux de faire vigile ?

"est-ce que je suis vraiment trop con pour faire de l'info et est ce que je ferais pas mieux de faire vigile ?"
j'adore cette confiance en soit ...

petoulachi a écrit a écrit : "est-ce que je suis vraiment trop con pour faire de l'info et est ce que je ferais pas mieux de faire vigile ?" j'adore cette confiance en soit ...

 
vi, moi aussi mais ya pas de t à soi

[edit]--Message édité par Moustaaki--[/edit]

Je crois que cette adresse va répondre à tes questions :
 
http://students.cs.byu.edu/~cs345ta/labs/qshell/

Encore mieux :
 http://www.codeproject.com/dialog/quickwin.asp

wai, le 2ème exemple, c'est des MFC, j'en ai encore jamais fait et j'ai un peu de mal à comprendre le code.
 
Pour le premier, ya un truc que je comprend po :
 
//create your 6 HANDLES prior to this    
 
   SECURITY_ATTRIBUTES saAttr;  
 
   saAttr.nLength = sizeof(SECURITY_ATTRIBUTES);  
   saAttr.bInheritHandle = TRUE;  
   saAttr.lpSecurityDescriptor = NULL;  
 
   CreatePipe(&errorReadHandle, &errorWriteHandle, &saAttr, 0);  
   CreatePipe(&outputReadHandle, &outputWriteHandle, &saAttr, 0);  
   CreatePipe(&inputReadHandle, &inputWriteHandle, &saAttr, 0);  
 
 
 
c'est des pointeurs sur quoi ? (Handle, c'est bien pointeur ?)
la fonction demande des types void ** , jamais vu ça qu'est que c'est ?
 
Comment dois-je déclaré les variables inputReadHandle, ... ?
 
 
je viens de voir que c'était :
HANDLE trucMachinSortie ;
 
  Si handle est bien un pointeur et bé, ça fait bysarre de faire un pointeur comme ça. Comment se passe l'alloc mémoire ? taille fixe ou dynamique ? (juste pour info)

[edit]--Message édité par Moustaaki--[/edit]

personne répond ? alors ...
Handle c'est le principe des pointeur mais c'est pas un vrai pointeur : un handle ne contient l'adresse de l'objet pointé mais un numéro l'identifiant dans une table (non accessible, sauf par windows) qui elle contient l'adresse ...
en gros je crois que c'est ca ...
ainsi tu ne peux pas modifier l'objet "pointé" par le handle, sauf en passant par les fonctions désignées, chargées de le faire (fonction à Windows)...
void * : pointeur sur n'importe quoi
void ** : un tableau de pointeurs sur n'importe quoi (tu peux remplcer void ** tableau par void * tableau[] ...)
 
"je viens de voir que c'était :  
HANDLE trucMachinSortie ;  
 
  Si handle est bien un pointeur et bé, ça fait bysarre de faire un pointeur comme ça. Comment se passe l'alloc mémoire ? taille fixe ou dynamique ? (juste pour info)"
 
ben HANDLE est un nombre et tu peux parfaitement le remplacer par unsigned long int .... ce nombre contient une reference (un handle = une poignee) vers un objet ...
au nivo de l'alloc, je saisi pas trop ce que tu veux dire, mais généralement c'est Windows qui se charge de tout.
quand tu souhaite un objet, Windows se le créé, se l'initialise, lui assigne un handle et te renvoit cet handle ...
 
bon je pense que c'est a peu pres ca ...
c'est aussi l'occasion pour moi de voir si j'ai bien tout pigé ...
n'hésitez donc surtout pas à corriger

ICI !!      
 
 

 
 
ce que je voulais dire c'est que : (corriger moi si je dit une grosse connerie)
lorsque tu fais :
int oLeboInt ;
 
win garde de la mémoire pour un objet de type int.
 
char * trucMachin ;
win garde de la mémoire pour le pointeur, donc la taille d'une  adresse + la taille d'un caractère sur lequel pointe le... pointeur.
 
et HANDLE truc ; ??
ça n'existe pas l'alloc dynamique en C++, non ?
 
parceque quand tu fais un tableau de caractère par exemple, tu peux pas modifier sa taille en court de prog...
 
 
donc il va garde une taille de mémoire fixe.
voilà, je me suis éclairci sur ma question.
 
bon, toujours est-il que tu m'as répondu :
HANDLE aura toujours la même taille, celle 'un unsigned long int.
 
c'était juste pour info.
 
 
 
 
Pour ce qui est de mon problème, j'ai un peu de mal mais je vais éssayer de trouver tout seul.
 
voilà ce que je compte faire, dites moi si c'est une bonne idée, dites moi si ya pas une autre solution plus simple, moin "bourine".
 
Je reprend tout le programme (j'en suis ravis ) pour faire 5 executable.
 
1 exe sera l'interface graphique : fenetre + menu.
les autres serviront à l'appel des différents dll, un pour chaque dll (je pourrais peut-étre faire un exe avec arguments qui me permettrait de sélectionner tel ou tel dll à l'execution ?)
 
donc, à la selection d'une option dans un menu, j'appele l'exe qui appel les dlls consoles avec CreateProcess après avoir créer les différents pipes d'entrée/sortie.
le processus créé ouvre les 2 boites de dialogues ouverture, sauvegarde.
pendant ce temps là, l'appli principal "écoute" les sorties et les affiches sur des boites de dialogue.  
 
mon pb, c'est que je ne sais pas trop comment faire pour prevenir l'application principal que l'autre processus est terminé.comme ça, ça serait possible ? :
// le prog appelant dll
printf("stop\0" ) ;
 
 
// le programme principal remarque les caractères stop et arrete la boucle d'écoute.
 
seulement, je ne sais pas trop comment comparer ce qu'il vient du pipe et les caractères 's''t''o''p'. j'avais déjà eu le même pb dans une appli réseau, pb que je n'ai pas eu le tps de résoudre. C'est un pb tout con mais je suis partit sur cette solution :
if (charBuf = 's')
// lire le suivant
 if (charBuf = 't')
  // lire le suivant, etc.
 
mais je trouve ça assez bourrin, comment pourrais-je comparer un string et le contenu du buffer ? autrement dit, comment modifier le contenu du buffer pour le transformer en string ?  
merci !

[edit]--Message édité par Moustaaki--[/edit]

j'ai peu de temps alors ...
"char * trucMachin ;  
win garde de la mémoire pour le pointeur, donc la taille d'une  adresse + la taille d'un caractère sur lequel pointe le... pointeur."
 
c'est le compilo qui fait tout ca + un pointeur est un unsigned long int ... il fait 4 octet (intel 32 bits) et basta
qu'il pointe sur des chars, sur des images de 1 Go, ton pointeur fait 4 octets point barre, il contient une adresse memeoire de 4 octets.
 
"donc la taille d'une  adresse + la taille d'un caractère sur lequel pointe"
 
si tu fais :
 
char * pointeur;
 
puis *pointeur = 'A';
 
ca va merder parseke y'a rien qui correspond à l'adresse pointe par ton pointeur : y'a pas de caractere réservé comme tu semble le comprendre ...
 
mais :
char caractere;
char *pointeur = &caractere;
*pointeur = 'A';
 
la ok, c nickel
 
pour ton histoire de synchronisation de process ... je sais pas si tu parles de thread (y'a eu plein de post la dessus presedement => recherche) ou alors attendre la fin d'un exe ..
 
pour attendre la fin d'un exe que tu as lancé c pas dur, une boucle sans fin (enfin presque) qui teste la valeur de retour de l'exe que tu as lancé ... documente toi sur GetExitCodeProcess ...
 
=> lien : c du VB mais c proche (API à fond)
http://perso.wanadoo.fr/eric.hanac [...] terAp.html
 
j'insiste : un pointeur = une adresse memoire et c'est tout
char * trucMachin ;  
=> garde de la mémoire pour le pointeur, donc la taille d'une  adresse, et c'est tout

ok, merci pour l'éclaircicement et merci pour le nom de la fonction GetExitCodeProcess, je crois que c'est exactement ça qu'il me faut. Parceque l'appli principal doit continuer à tourner sur une boucle en testant si elle reçoit des caractères et en même temps tester si l'appli appelée s'est terminée ou pas.
 
je pense que je vais y arriver, maintenant, merci, et à +
 
( c'est vraiment de la merde les pointeurs , VIVE le JAVA !!!! )
 
 
les pointeurs :    et

[edit]--Message édité par Moustaaki--[/edit]