Prüfen, ob Prozess läuft

  • VB.NET

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von FatFire.

    Prüfen, ob Prozess läuft

    Hallo zusammen,

    ich bin noch neu im Gebiet Visual Basic und bräuchte mal eure Hilfe...
    Und zwar bastel ich momentan an einem Programm nur jetz komme ich nicht weiter...
    Und zwar habe ich folgendes vor:
    Ich möchte z.B. den Prozess msnmsg.exe prüfen ob er läuft (nicht starten nur prüfen).
    Wenn er läuft soll RadioButton1 markiert werden und wenn er nicht läuft dann soll RadioButton2 markiert werden...
    Bitte um Hilfe...
    komme einfach nicht weiter...

    MfG
    dennis1

    *Threadtitel gekürzt*

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    LaVendetta schrieb:

    Gugi schrieb:

    ich würds so machen:

    VB.NET-Quellcode

    1. For Each Process In Process.GetProcesses
    2. If Process.Name.Contains("msnmsg") then
    3. 'er existiert!
    4. End If
    5. Next


    lg Gugi
    1. Ist das nicht sooo gut.
    2. System.Diagnostics.Process.GetProcesses
    3. Process.ProcessName.Contains...

    1. Kannst du diese aussage begründen?
    2. System.Diagnostics.Process.GetProcesses() ergibt genau das selbe wie Process.GetProcesses()
    3. Hab ich gemacht da ich nicht wusste ob man die dateiendung dazuschreiben muss^^

    lg Gugi
    zu 1) Dein Beispiel braucht mehr Code, als das Beispiel von LaVendetta und umso kürzer der Code desto weniger Fehler schleichen sich ein und man findet sich leicht zurecht
    zu 2) Das ist gleiche, wenn man System.Diagnostic importiert, dann recht auch die Schreibweise von Gugi
    zu 3) Die Dateiendung wird nicht benötigt.
    Ähm singu & gugi , wenn man bei For each Process in ...
    Process.GetProcessByName ("...") macht kommt ein error,
    wenn man System.Diagnostics.Process.GetProcessByName ("...")
    Kommt keiner.
    EDIT: Woher weißt du ob ers Importet hat??

    LaVendetta schrieb:

    Ähm singu & gugi , wenn man bei For each Process in ...
    Process.GetProcessByName ("...") macht kommt ein error,
    wenn man System.Diagnostics.Process.GetProcessByName ("...")
    Kommt keiner.
    EDIT: Woher weißt du ob ers Importet hat??

    1. was ist bei den 2 der unterschied ?(
    2. system.diagnostics braucht man nicht importieren. das kann man auch so verwenden...

    lg Gugi
    EDIT:

    Dieser Beitrag wurde bereits 2407 mal editiert, zuletzt von »LaVendetta« (37. Dezember 2019, 27:67) aus folgendem Grund: Fail

    lol, wie hast du das gemacht? :P

    LaVendetta schrieb:

    Ähm singu & gugi , wenn man bei For each Process in ...
    Process.GetProcessByName ("...") macht kommt ein error,
    wenn man System.Diagnostics.Process.GetProcessByName ("...")
    Kommt keiner.
    EDIT: Woher weißt du ob ers Importet hat??

    Ich hab es jetzt gerade ausprobiert und bei mir kommt kein Fehler. Welcher Fehler kommt bei dir?

    Quellcode

    1. Fehler 1 Der Typ "Process" kann nicht von einem Ausdruck abgeleitet werden, der "Process" enthält. C:\Users\XXXXXX\AppData\Local\Temporary Projects\WindowsApplication2\Form1.vb 5 29 WindowsApplication2


    Unterstrichen ist Process.GetProcesses in der For-Zeile da.
    Wenn ichs mit System.Diagnostics.Process.GetProcesses tauschen gehts,
    außerdem hab ich auch:

    VB.NET-Quellcode

    1. Imports System.Diagnostics
    2. 'und
    3. Imports System.Diagnostics.Process

    VB.NET-Quellcode

    1. If System.Diagnostics.Process. _
    2. GetProcessesByName("msnmsg").Length > 0 Then
    3. RadioButton1.Checked = True
    4. Else
    5. RadioButton2.Checked = True
    6. End If


    Sowohl LaVendettas als auch Gugis Lösung sind Mumpitz. Was soll ich mit einer For Each-Schleife, wenn ich nur wissen will, ob es Prozesse mit dem Namen gibt?
    Ob ich mit Imports oder nicht arbeite, hängt ein bisschen davon ab, wie oft ich den Kram brauche. Wenn das die einzige Stelle ist an der ich Dinge aus dem Namespace brauche, kann ich auch mit dem voll qualifizierenden Namen arbeiten (weil keine Codeeinsparung wenn ich den Namenspace importiere und Mehraufwand für den Compiler).

    Gruß FatFire

    PS: Wenn ich schon durch Einträge in einer Liste, die sich jederzeit ändern kann, iteriere, dann mach ich mir vorher eine lokale Kopie davon:

    VB.NET-Quellcode

    1. Dim Prozesse As Process() = Process.GetProcesses
    2. For Each Prozess as Process In Prozesse
    3. ' Mach Deinen Kram
    4. Next

    FatFire schrieb:

    und Mehraufwand für den Compiler



    Der Compiler ist AFAIK schlau genug bei nur wenigen Verwendungen des Imports einen Inline-Aufruf draus zu machen.

    //EDIT: Ah ok, da hab ich was missverstanden, siehe Post ↓

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „vredesbyrD“ ()

    Ich kann mir halt vorstellen, dass der Compiler bei Angabe von

    VB.NET-Quellcode

    1. System.Diagnostics.Process.GetProcesses

    die nötigen Informationen schneller findet als wenn man

    VB.NET-Quellcode

    1. Imports System.Diagnostics.Process
    2. ' und später dann
    3. GetProcesses()

    Er durchsucht ja dann alle importierten Namespaces nach der Methode, während er bei ersterem an die Hand genommen dahingeführt wird.

    Aber um ehrlich zu sein hab ich keine Ahnung wie schlau die Compiler heute sind, also würde es mich nicht wundern, wenn der Vorteil gegen 0 geht.

    Gruß FatFire
    Ja die Compiler sind heute ziemlich schlau ;) Man kann im IL Code erkennen, dass dieser aus

    VB.NET-Quellcode

    1. Imports System.Diagnostics
    2. Public Class xD
    3. Private pr As Process
    4. End Class

    (natürlich nur vom Prinzip her, IL Code würde anders aussehen^^) vollgendes macht:

    VB.NET-Quellcode

    1. Public Class xD
    2. Private pr As System.Diagnostics.Process
    3. End Class

    das heißt es wird bereits beim Kompilieren des Programms zu einer Executable im IL Code entsprechend gesucht und umgesetzt, sodass kein Geschwindigkeitsunterschied sichtbar sein sollte...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---