Daten an andere .exe übergeben

  • Allgemein

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Daten an andere .exe übergeben

    Hallo!

    Ist es möglich, Daten an eine andere exe zu senden? Die andere exe ist jetzt nicht irgendeine fremde Komponente sondern eine von mir geschriebene Anwendung. Die Schnittstelle ist also bekannt. Der Einfachheit halber soll die exe für das Beispiel hier nur ein Form (Form1) und sonst nichts haben.

    Das Form1 soll jetzt - aus dem anderen Programm heraus - eine neue Caption bekommen, sagen wir mal: Form1.Text = "Hallo".

    Hat jemand eine Idee?

    Philipp

    Das geht nur über API.
    Per Process.Start() bekommst Du das Windows-Handle dieser Anwendung und kannst dann per API.SendMessage() und Co sehr viel machen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das ging aber flott
    Danke Rod!

    Kleiner Reim, mir war danach.

    Nachdem ich jetzt ein wenig recherchiert habe muss ich aber leider feststellen, dass das meine Fähigkeiten überschreitet. Alle gefundenen Besipiele zeigen mir nur Teillösungen. Das zu einem Ganzen zusammenzubauen ist mir noch nicht gelungen. Aber dennoch, danke schon mal für die Richtung. Ich probier weiter rum...

    Gruß

    Eine noch besser Lösung wären aus meiner Sicht die, in .Net verankerten, Pipes zu nutzen.
    Hierbei steht ein Stream beiden Anwendungen zur Verfügung. (Ähnlich wie bei einer Tcp Verbindung)
    Schau dir einfach mal das für den Server an (Die Anwendung die warten soll, wenns egal ist, such dir einfach eine aus ;) ) und das für den Client.
    Beide Beispiele sind in C# geschrieben sollten sich aber recht leicht konvertieren lassen, wenn man das prinzip verstanden hat.
    Wenn du weitere Hilfe brauchst, sag bescheid.

    Schönes Wochende und Viel Erfolg

    Christian

    Hallo Christian,

    genau danach habe ich gesucht, hat mir sehr geholfen. Ich habe mir anhand des Beispiels eben was zusmmenbauen können.

    Die PipeSendApp sieht so aus:

    VB.NET-Quellcode

    1. Imports System
    2. Imports System.IO
    3. Imports System.IO.Pipes
    5. Public Class Form1
    7. Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
    9. Dim p As New NamedPipeClientStream("UniqueString")
    10. p.Connect()
    11. Using w = New StreamWriter(p)
    12. w.WriteLine(Now)
    13. End Using
    15. End Sub
    17. End Class

    Und die PipeReceiveApp dergestalt:

    VB.NET-Quellcode

    1. Imports System.IO
    2. Imports System.IO.Pipes
    4. Public Class Form1
    6. Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
    7. StarteServer()
    8. End Sub
    10. Sub StarteServer()
    12. Dim Received As String
    14. Using p = New NamedPipeServerStream("UniqueString")
    15. p.WaitForConnection()
    16. Dim streamReader As New StreamReader(p)
    17. Received = streamReader.ReadLine()
    18. End Using
    20. ListBoxReceive.Items.Add(Received)
    21. ListBoxReceive.Refresh()
    23. StarteServer()
    25. End Sub
    27. End Class

    Klappt soweit ganz gut. Muss mir als nächstes übelegen, wie ich die PipeReceiveApp händisch wieder stoppen kann. Solange p.WaitForConnection() läuft kann ich in dem Form gar nichts machen.

    Gruß

    Philipp66 schrieb:

    VB.NET-Quellcode

    1. StarteServer()
    Warum rufst Du StarteServer() un der Prozedur StarteServer() rekursiv auf?
    Nimm es mal raus.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

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

    Da kommt das Threading ins Spiel: du musst einen neuen Thread erstellen und starten.
    Das machst du so:

    VB.NET-Quellcode

    1. Dim myThread As Threading.Thread = New Threading.Thread(AddressOf AuszuführendeSub)
    2. myThread.Start()


    Wie Rod gesagt hat, kannst du hier besser eine While-Schleife benutzen.
    Ich denke, dass NamedPipeClientStream irgendeine Eigenschaft hat, die beschreibt, ob verbunden oder nicht.

    VB.NET-Quellcode

    1. Sub Listen()
    3. Dim Received As String
    5. Using p = New NamedPipeServerStream("UniqueString")
    6. p.WaitForConnection()
    7. Dim streamReader As New StreamReader(p)
    8. While p.IsConnected = True
    9. 'In Listbox schreiben
    10. 'ACHTUNG: hier muss mit Invokes gearbeitet werden
    11. End While
    12. End Using
    13. End Sub

    @Myrax: Auch bei dem Ansatz stoppt mein Listener nach dem ersten Connect.

    Ich habe jetzt das gemacht um rauszukommen:

    VB.NET-Quellcode

    1. If Received <> "STOPP" Then StarteServer()

    Alles andere als schön aber nun ja.... jeder so wie er kann.

    Ich möchte mir eine Desktop-Sidebar basteln, die laufend Informationen aus anderen Anwendung empfangen kann. Mit andere Anwendungen meine ich selbst geschriebene. Im konkreten Fall geht es unter anderem um eine Stoppuhr. Ich messse in meinem Projekt bei einigen Codeblöcken die Bearbeitungszeit. Vor und nach dem zu messenden Bereich übergebe ich meiner Klasse Stoppuhr ein .AddDuration. Und weil ich das Ergebnis auch noch sehen möchte, nachdem ich meine Anwendung gestoppt habe, brauche ich eine seperate Applikation.

    Natürlich geht das auch anders. Logo. Momentan sammel ich meine Durations ja auch und stelle sie dann in einem Form dar, das innerhalb der Anwendung aufgerufen wird. Ich will aber unbedingt meine Messergebnisse außerhalb des Clients verwalten.

    So in etwa:


    :) Philipp

    cooles Gerät :thumbsup:

    Prinzipiell eine ganz typische Server-Client-Architektur, Observer-Pattern mit allem Pipapo.

    Vlt. nutzt dir VersuchsChat - der hat nämlich 100% dieselbe Struktur, nur kommuniziert der per TCP.
    Iwann werd ich den mal umstricken auf NamedPipes.
    Strukturell erfüllt nämlich der Name einer NamedPipe dieselbe Funktion wie die Server-IP beim Tcp-Netz - an der Klassenstruktur vom VersuchsChat wäre also nix zu ändern.

Facebook
Telefonspende