Anzeige:
Ergebnis 1 bis 5 von 5

Thema: Programmausgaben umleiten

  1. #1
    Registrierter Benutzer
    Registriert seit
    02.10.2002
    Ort
    Witten
    Beiträge
    41

    Programmausgaben umleiten

    hi,

    ibt es irgendeine möglichkeit, mit den Qt- Bibs 2.3 die Ausgabe von Programmen umzuleiten, und wenn ja, kann man mir vielleicht ein kleines Beispiel geben.
    am besten wäre es noch, wenn man das andere programm nicht sichtbar wird.

    Hab es schon mal hiermit probiert, aber da kommt kein vernünftiges Ergebnis bei raus. Sagen wir besser es kommt gar nichts bei raus.
    Code:
       char   psBuffer[128];
       FILE   *drives;
    
        /* Run cdrdao to scan the scsi bus for drives */
       if( drives= _popen( "cdrdao scanbus", "r" )) == NULL ) // hab auch rt und rb schon ausprobiert
          exit( 1 );
    
       /* Read pipe until end of file. End of file indicates that 
       * drives closed its standard out (probably meaning it 
       * terminated).
       */
       while( !feof( drives) )
       {
          if( fgets( psBuffer, 128, drives) != NULL )
    		  m_StdOut += psBuffer;
       }
       /* Close pipe */
       _pclose( chkdsk );
       // Ausgabe nur zum test wird dann weiterverarbeitet
       QMessageBox::information(0, "", m_StdOut);

  2. #2
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Hmm.
    Qt2.3 deutet auf Windows hin.

    popen ist aber POSIX

    Heißt es darum in deinem Code _popen statt popen?

    Falls m_StdOut ein QString ist, solltest du den char Buffer zuerst mit QString::fromLocal8Bit umwandeln.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  3. #3
    Registrierter Benutzer
    Registriert seit
    02.10.2002
    Ort
    Witten
    Beiträge
    41
    Ja, es ist unter Windows.
    Nein, es sollte eigentlich keine POSIX sein, das stand da in der MSDN.
    gibt es denn sonst überhaupt keine Möglichkeit die Ausgabe umzuleiten unter QT.
    auch mit fromLocal8Bit() klappts nicht.

    HeReSY

    Ich habe das gleiche auch mal mit cdrecord ausprobiert, und da klappt die Augabe. Muß dann ja eigentlich an cdrdao liegen.

  4. #4
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von HeReSY
    Ja, es ist unter Windows.
    Nein, es sollte eigentlich keine POSIX sein, das stand da in der MSDN.
    Ziemlich sicher Teil der POSIX Schnittstelle von NT
    Oder zumindest API die sie von dort abgekupfert haben.


    gibt es denn sonst überhaupt keine Möglichkeit die Ausgabe umzuleiten unter QT.
    Hmm, unter Qt3 gibt es QProcess.
    Der arbeitet unter Windows wahrscheinlich mit WinAPI Funktionen.


    auch mit fromLocal8Bit() klappts nicht.
    Wäre nichts desto Trotz eine gute Idee
    Encoding und so.


    Ich habe das gleiche auch mal mit cdrecord ausprobiert, und da klappt die Augabe. Muß dann ja eigentlich an cdrdao liegen.
    Vielleicht schreibt das nach stderr.
    Kann man unter Windows stderr in den stdout umleiten?

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  5. #5
    Registrierter Benutzer
    Registriert seit
    02.10.2002
    Ort
    Witten
    Beiträge
    41
    Ziemlich sicher Teil der POSIX Schnittstelle von NT
    Oder zumindest API die sie von dort abgekupfert haben.
    Ja das stimmt, hab ich aber erst später nachgelesen.

    Hmm, unter Qt3 gibt es QProcess.
    Der arbeitet unter Windows wahrscheinlich mit WinAPI Funktionen.
    Da ich das Prog für Windows brauch, kann ich leider nichts mit der 3er anfangen.

    Wäre nichts desto Trotz eine gute Idee
    Encoding und so.
    Werde ich beachten!

    Vielleicht schreibt das nach stderr.
    Kann man unter Windows stderr in den stdout umleiten?
    Wenn ich die WinAPI Funktionen nehme, dann klappt das ja auch. Doch der Quelltext ist mega lang. Und da hab ich gedacht, das einer etwas besseres weiß.

    HeReSY

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •