Prozess laufende Prozesse abfragen und auf Gültigkeit überprüfen
-
Hallo Forum,
hat von euch schonmal jemand mehr gemacht als nur ein Programm zu starten? Ich möchte gerne herausbekommen welche Prozesse laufen und diese dann überwachen.
Habe einen Homeserver zuhause und möchte dort ein Prozess überwachen ob dieser läuft oder nicht.Gruß
Alex
-
Meinst du starten über QProcess?
Ich starte regelmässig mehrere Prozesse über QProcess von meinen Applikationen. Dies sollte eignetlich kein Problem sein. Ich mache das auf Windows und es sollte auch auf Linux funktionieren. Allerdings mit der Kontrolle über eine weitere Applikation sehe ich Probleme. Auf Windows ist die Process ID nicht eindeutig zuweisbar. Ich verwalte daher meine Prozesse in der Applikation aus der gestartet wurde.
-
Also Prozesse kann ich normal aus der Applikation starten.
z.B.:@#include <QCoreApplication>
#include <QDebug>
#include <QProcess>int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);QProcess *myPro = new QProcess(); bool ok = myPro->startDetached("notepad.exe"); if(ok) qDebug()<<"TRUE"; else qDebug()<<"FALSE"; return a.exec();}
@Die if ist somit wahr sobald notepad.exe gestartet ist. Nun möchte ich aber überwachen ob dieses Programm geöffnet ist oder nicht. Sprich das Programm soll nun die Überwachung machen.
Soweit ist es klar. Aber die Überwachung noch nicht ganz.
-
Eine direkte Frage: wie weit kennst du dich in objektorientierter Programmierug aus respektive C++ aus? Die untenangegebenen Kommentare Zielen auf OOP ab.
Das Starten von Programmen, wie du es gemacht hast, ist so möglich. Allerdings sind Qt-Programme in der Regel auf Objekte aufgebaut. QProcess würde dann in einer Klasse gestartet und mittels der "Signal-Slot-Mechanik":https://qt-project.org/doc/qt-5/signalsandslots.html erhält man Signale wenn etwas mit der Applikation passiert. Da kannst du dann individuell reagieren.
-
Jeder muss mal klein anfangen ;-)
War mir nicht sicher, da du alles in das main gepackt hast.
Schaue dir mal die Signal-Slot-Mechanik an. Es ist ganz clever gemacht. Auch wenn es relativ einfach ist, blickt man nicht auf Anhieb durch (ging mir auch so).QCoreApplication-Klasse beherbergt das Event-Handling. Du hast wahrscheinlich gemerkt, dass das Programm, wenn gestartet und nicht crasht, endlos weiterläuft. Es bleibt im a.exec() und kann die Events/Signale weiterverarbeiten. Signale werden mit Slots verbunden. Diese Slots sind nichts anderes als normale Routinen in deiner Klasse. Der einzige Unterschied kommt in der Deklarierung.
-
Ja das stimmt :-) und wenn man mal das eine oder andere Programm zum laufen bekommt erfreut es doch einen sehr :-D
Okay. Dann schaue ich mal in der Doku mit die Signal-Slot-Mechanik mal an ob ich das richtig verstehe :-)
Welchen Unterschied meinst du genau? Das stimmt das das Programm endlos in dem sinne läuft. Und diese Routine kann ich her nehmen und für meine zwecke nutzen?
gruß
alex
-
[quote author="nickvan86" date="1397033785"]
Welchen Unterschied meinst du genau? Das stimmt das das Programm endlos in dem sinne läuft. Und diese Routine kann ich her nehmen und für meine zwecke nutzen?
[/quote]Die Unterschiede liegen in der Vererbung von QObject, dem Macro Q_OBJECT in header file und das die Slots unter der Rubrik: "public slots:" stehen. Im Endeffekt sind es aber ganz normale Methoden in deiner Klasse. Mit Signal&Slots kannst du verschiedene Klassen aufeinander reagieren lassen ohne ständig wieder zu überprüfen.
In deinem Falle kannst auf ein Signal von QProcess warten bis irgendetwas auftritt. Z.B. sendet QProcess ein Signal "finished(...)":http://qt-project.org/doc/qt-5/qprocess.html#finished wenn die gestartete Applikation endet. Die Parameter sagen dir auch einige Details.
-
also habe mir mal das Beispiel mit notepad.exe angeschaut. nun habe ich etwas ausprobiert. Ich schreibe mir mit folgenden Befehl den Pfad der exe in ein txt Dokument und Speicher dies ab.
@ QString filename = QFileDialog::getOpenFileName(this,"Open .exe","C://","All files(.);;");
if(filename == NULL)
QMessageBox::information(this,".exe","Keine *.exe gewählt.");
else
{
ui->dateiEdit1->setText(filename);QDir pfad1(QCoreApplication::applicationDirPath()); QFile var1(pfad1.absolutePath()+QDir::separator()+("process.txt")); QFile processFile(var1.fileName()); if(!processFile.open(QIODevice::WriteOnly | QIODevice::Text)) //Append für Dranhängen QMessageBox::critical(this,"ERROR","Fehler beim öffnen der Datei"); else { QTextStream out(&processFile); QString var2 = ui->dateiEdit1->text(); out << var2; //out << "\n"; //Für Mehrzeilige Prozesse bei Append } processFile.close(); }@Soweit so gut. Da Ich nun den Pfad habe lade ich mir den später in einen String und übergebe ihn dem qprocess:
@QDir pfad1(QCoreApplication::applicationDirPath());
QFile var1(pfad1.absolutePath()+QDir::separator()+("start.png"));QDir pfad2(QCoreApplication::applicationDirPath()); QFile var2(pfad2.absolutePath()+QDir::separator()+("stop.png")); QDir pfad3(QCoreApplication::applicationDirPath()); QFile var3(pfad3.absolutePath()+QDir::separator()+("process.txt")); QFile processFile(var3.fileName()); if(!processFile.open(QIODevice::ReadOnly | QIODevice::Text)) QMessageBox::critical(this,"ERROR","Fehler beim öffnen der Datei"); else { QTextStream in(&processFile); ui->process1->setText(in.readAll()); } processFile.close(); QProcess *process1 = new QProcess(); QString program = ui->process1->text(); qDebug() << program; process1->start(program);@Leider startet mein Programm (in dem Fall Firefox) nicht und das Programm kotzt ab.
-
Den Pointer in der Klasse behalten und keinen temporären Pointer verwenden.
Das funktioniert eigentlich meist noch recht gut den Pointer in der Gegend herumhängen zu lassen. ;-) Fällt meist Monate später auf, wenn man irgendeine andere Änderung macht und einem alles um die Ohren fliegt.
Zum Beispiel dann im Headerfile MeineKlasse.h:
@
class MeineKlasse : public QObejct
{
Q_OBJECT.... QProcess *ProcessPtr;};
@
und in source File MeineKlasse.cpp:
@
...
ProcessPtr = new QProcess();
QString program = ui->process1->text();
qDebug() << program;
ProcessPtr->start(program);
@Noch eine Anmerkung. Versuche etwas Struktur in deine Namensgebung zu bringen. Nicht überall denselben Namen und Schwreibweise, wie mit process1. Wenn dies immer wso machst, bekommst du ein heilloses Durcheinander.
Manche starten die Klassenmembernamen alle mit m_ (m_Process...). Bei mir starten alle Membernamen mit einem Grossbuchstaben und lokale Variablen mit einem kleinen. Hilft schon viel ;-)
-
Hi,
also bei
@
qDebug() << program;
@gibt er mir den Pfad zur exe von Firefox aus und bei
@
ProcessPtr->start(program);
@startet firefox nicht.
@
Starting C:\Users\bauralexander\Desktop\build-ProcessMonitoring-Desktop_Qt_5_2_1_MinGW_32bit-Debug\debug\ProcessMonitoring.exe...
"C:/Program Files (x86)/Mozilla Firefox/firefox.exe"
@Pfadschreibweise so in Ordnung?
[edit: Klammeraffen verschoben und blanks eingeführt wegen falscher Anzeige, koahnig]
-
Problem sind die spaces im Datenamen,
Da du nur den Befehl eingibst führt QProcess dies als "C:/Program" und den Rest als Parameter aus.
Du musst den Befehl schon in Anführungszeichen setzen. Die Aufgezeigten werden von qDebug eingeführt, So kann man die Länge des Strings sehen.Probiere es erst einmal mit
@
program = ""C:/Program Files (x86)/Mozilla Firefox/firefox.exe"";
ProcessPtr->start ( program);
@ -
Ah super so hat es geklappt.
Hab es auch für mein Auslesen aus einer Textdatei hin bekommen :-)
@QProcess *process1 = new QProcess();
QString program = ui->process1->text();
QString first = """;
QString last = """;
program.insert(0,first);
program.insert(program.size(),last);
qDebug()<<program;
process1->start(program);@Nun muss ich halt schauen wie ich diesen Prozess (Firefox) richtig überwachen kann, falls das Program jemand schließt oder der Prozess nicht mehr ausgeführt wird.
-
Eine Alternative ist das 8.3-Format, wie von Clochydd angegeben.
Persönlich mag ich das gar nicht. Es erinnert mich zu sehr an die DOS-Zeiten respektive Lochkarten.
Für den Rest musst du dich mal vertieft mit den Signals&Slots auseinandersetzen. Vom Prinzip her sind das eigentlich nichts anderes als Aufrufen zu Routinen einer Klasse.Das Gnaze ist nur abstrahiert. Auf der aufrufenden Seite wird es SIGNAL genannt und auf der anderen SLOT.