Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1384 connectés 

  FORUM HardWare.fr
  Programmation

  [Borland C++ builder] Redirection sdtout

 
 


Dernière réponse
Sujet : [Borland C++ builder] Redirection sdtout
Bruce un cht'i up car bon... je suis tj bloqué...

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
Bruce un cht'i up car bon... je suis tj bloqué...
JWhy oui... je vois pas pourquoi vous lui parlez de threads ...
 
comme je te disais, le probleme vient de ReadFile qui est bloquant tant que rien n'est ecrit dans ton stdout... c'est a dire que si tu as un prog qui va ecrire un truc, attendre 5 secondes, ecrire un autre truc, readfile va bloquer ton appli pendant les 5 secondes ou le prog. n'ecrit rien dans le stdout...
 
 
il faut que tu remplaces le ReadFile bloquant:

Citation :


  if(ReadFile(hReadPipe, &dest, sizeof(dest), &BytesRead, NULL)) {
   [...]
  }


 
par un test pour savoir si il y a qqchose a lire et ensuite, si il y a qqchose, le lire (qui ne sera pas bloquant puisque tu vas lire exactement ce qu'il y a):

Citation :


  PeekNamedPipe (hOutPipeRead, nil, 0, @dwRead, @dwLeft, nil);  
 
  // has anything been read?  
  if (dwLeft <> 0) then  
  begin  
    ReadFile(hOutPipeRead, Buffer, dwLeft, dwRead, nil);  
    [...]
  end;

Bruce Honettement je suis un peu paumé, je vois pas trop ou vous voulez en venir (il faut dire que jes thread et moi... :)).
robripper Tu crées juste un thread, tu lui passes ta fonction en param (cell qui va faire tout le travail)... etc
 
En plus ici t'es pas obligé de section critique donc ...
 
DWORD WINAPI ma_fonction(LPVOID)
{
 
       // ... rippage, normalisation, etc etc ...  :sol:  
 
      return 0;
}
antp

robripper a écrit a écrit :

Franchement moi j'utiliserais l'API c'est bien plus simple, je viens de jetter un oeil dans c++ builder  :D  
Attention, bientôt il va te faire utiliser Delphi, je connais bien antp  :hap:  :hap:




 
ok pour l'API
avec Delphi le .exe serait moins gros :P
robripper Franchement moi j'utiliserais l'API c'est bien plus simple, je viens de jetter un oeil dans c++ builder  :D  
Attention, bientôt il va te faire utiliser Delphi, je connais bien antp  :hap:  :hap:
antp

bruce a écrit a écrit :

Hu ?  :??:




 
prend l'aide de Builder à "TThread" je crois que c'est ce qu'il y aura de plus facile pour commencer...
sinon dans les exemples fournis il doit bien y en avoir un qui fait ça...
robripper Tu peux aussi modifier les priorités ...
 
SetThreadPriority(threadhandle,THREAD_PRIORITY_NORMAL);
Bruce Hu ?  :??:
antp

robripper a écrit a écrit :

 
 
DWORD threadid;
HANDLE threadhandle;
 
...
threadhandle = CreateThread(NULL,1024,ma_fonction,NULL,CREATE_SUSPENDED,&threadid);
...
TerminateThread(threadhandle,0);
 




 
y a aussi la classe TThread.
Moi j'utiliserais celle-ci, ça a l'air plus simple :)

 

[edit]--Message édité par antp--[/edit]
robripper

bruce a écrit a écrit :

Hummm... disons que je m'y connais mal ;)




 
DWORD threadid;
HANDLE threadhandle;
 
...
threadhandle = CreateThread(NULL,1024,ma_fonction,NULL,CREATE_SUSPENDED,&threadid);
...
TerminateThread(threadhandle,0);
 
==================
 
 
DWORD WINAPI ma_fonction(LPVOID)
{
       EnterCriticalSection(&crit);
 
       // ... travail ...
 
       LeaveCriticalSection(&crit);
      return 0;
}
Bruce Hummm... disons que je m'y connais mal ;)
antp pourquoi en win32 ? y a des objets pour faire des threads dans C++builder, c'est plus simple à utiliser je crois.
Bruce Heu... en Win32 j'ai du mal, un exemple de code ???
robripper

antp a écrit a écrit :

ha ouais c'est au WaitForSingleObject(pi.hProcess, 90000); qu'il bloque... j'avais pas vu.
le plus simple serait alors de le mettre dans un thread séparé je crois.




 
un thread séparé, c le truc à faire en effet...
antp ou alors:
while(!WaitForSingleObject(pi.hProcess, 1000))
{
  Application->ProcessMessages();
}
 
toutes les secondes il fait le processmessages.
je sais pas si c'est très bien comme solution.
et si le programme exécuté est calé il attend indéfiniment.
antp ha ouais c'est au WaitForSingleObject(pi.hProcess, 90000); qu'il bloque... j'avais pas vu.
le plus simple serait alors de le mettre dans un thread séparé je crois.
JWhy m'etonnerait que ca marche... c'est l'appel de l'API qui est bloquant... le ProcessMessage ne resoudra rien, je pense ...
 
sinon, regarde l'aide de l'API PeekNamedPipe, la declaration en C + le code Delphi devrait pouvoir t'aider a faire la conversion .
antp si tu le met juste après le ->add il risque de pas le faire souvent pour les longues opérations
si tu le met dans la boucle en dehors du if c'est dangereux pcq ton appli risque de prendre trop de CPU pour rafraichir... il faut tester
Bruce Pas con, je vais essayer.
antp pour éviter que ça bloque il faut faire régulièrement des Application->ProcessMessages(); c'est-à dire juste après le memo->lines->add.
Peut-être que ça résoudra l'autre problème en même temps...

 

[edit]--Message édité par antp--[/edit]
Bruce Heu... bon, je doit avouer avoir du mal à piger ta syntaxe... Le pascal est qd même légèrement différent... :)
JWhy

Code :
  1. procedure TProcess.ReadScreen;
  2. var
  3.   Buffer: array[0..255] of Char;
  4.   dwLeft, dwRead : DWORD;
  5. begin
  6. //  FillChar(Buffer, SizeOf(Buffer), 0);
  7.   dwLeft := 0;
  8.   dwRead := 0;
  10.   FLastLines := '';
  11.   PeekNamedPipe (hOutPipeRead, nil, 0, @dwRead, @dwLeft, nil);
  13.   // has anything been read?
  14.   if (dwLeft <> 0) then
  15.   begin
  16.     ReadFile(hOutPipeRead, Buffer, dwLeft, dwRead, nil);
  17.     // finish buffer to PChar
  18.     Buffer[dwRead] := #0;
  19.     // combine the buffer with the rest of the last run
  20.     FLastLines := Buffer;
  21.     FLines := FLines + Buffer ;
  22.   end;
  23. end;
JWhy beuh... j'fais du Delphi, moi...  mais je vais essayer de te trouver un bout de code relativement clair...
Bruce Heu... tu n'aurrai pas un exemple de code qq part car je suis pas encore bien pro en prog... J'ai pompé ça sur un exemple fourni avec BC++ en adaptant à mes besoins...
 
Merci encore ! :)
JWhy oui, c'est normal... je me suis fait avoir de la meme facon...

Citation :


ReadFile returns when one of the following is true: a write operation completes on the write end of the pipe, the number of bytes requested has been read, or an error occurs.


c'est a dire que tant que tu n'ecris rien, ca ne "revient" pas et donc ton prog. est bloqué..
l'astuce (merci minicooler :jap: ) est d'utiliser l'API PeekNamedPipe pour savoir si il y a qqchose d'ecrit et si c'est le cas, utiliser ReadFile pour recuperer le contenu !
Bruce J'ai trouvé comment rediriger stdout
quasiment comme je le voulais (Je suis sous
Borland c++ 4.0)
Voilà, cela marche mais j'aimerais que cela marche légèrement différement...
En effet, lorsque je lance ma commande, je suis obligé d'attendre que cette
commande soit terminée pour que le résultat s'affiche dans mon Memo... De
plus, tous le temps de la commande, l'application est comme "bloquée",
impossible de déplacer la fenêtre par exemple...
Si qq un peu m'aider, cela serait vraiment sympa... Merci d'avance !
Voici mon code :
(précision, Rippack_RipFormBeta->Memo1 est le mémo dans lequel je sort,
filepos est ma ligne de commande)
 

Code :
  1. Rippack_RipFormBeta->Memo1->Clear();
  3. int FBreak;
  4. HANDLE hReadPipe;
  5. HANDLE hWritePipe;
  6. STARTUPINFO si;
  7. LPSECURITY_ATTRIBUTES lpsa = NULL;
  9. if(CreatePipe(&hReadPipe,&hWritePipe,lpsa,0))
  10. {
  11.   memset(&si, 0, sizeof(STARTUPINFO));
  12.   si.cb = sizeof(STARTUPINFO);
  13.   si.dwFlags = STARTF_USESHOWWINDOW |STARTF_USESTDHANDLES;
  14.   si.wShowWindow = SW_HIDE;
  15.   si.hStdOutput = hWritePipe;
  16.   si.hStdError = hWritePipe;
  17.   PROCESS_INFORMATION pi;
  18.   if(hWritePipe)
  19.   {
  20.     Rippack_RipFormBeta->Memo1->Lines->Add("Working..." );
  21.     Application->ProcessMessages();
  23.     if(CreateProcess(NULL,filepos.c_str(),NULL,NULL,TRUE,0,0,0,&si,&pi))
  24.     {
  25.       CloseHandle(pi.hThread);
  26.       WaitForSingleObject(pi.hProcess, 90000);
  27.       if(hReadPipe)
  28.       {
  29.         DWORD BytesRead; //unsigned long
  30.         char dest[4000];
  31.         bool RdLoopDone = false;
  33.         Rippack_RipFormBeta->Memo1->Clear();
  35.         FBreak = 1;
  36.         if(ExitCode) Screen->Cursor = crDefault;
  37.         while(!RdLoopDone)
  38.         {
  39.           memset(dest, 0, 4000);
  40.           if(ReadFile(hReadPipe, &dest, sizeof(dest), &BytesRead,
  41. NULL))
  42.           {
  43.             Rippack_RipFormBeta->Memo1->Lines->Add(String(dest));
  44.             if(BytesRead < 4000) RdLoopDone = true;
  45.             if(FBreak > 150) RdLoopDone = true;
  46.             FBreak++;
  48.             CloseHandle(hReadPipe);
  49.             CloseHandle(hWritePipe);
  50.             CloseHandle(pi.hProcess);
  51.           }
  52.         }
  53.       }
  54.     }
  55.   }
  56. }
 

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

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR