Automatisierungsprobleme beim Auslesen und Fernsteuern externer Programme

  • Allgemein

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von VaporiZed.

    Automatisierungsprobleme beim Auslesen und Fernsteuern externer Programme

    Hallo zusammen,

    ich habe das Problem, dass die Menüs (MenuStrips) in aktuellen .Net-Programmen nicht mehr durch P/Invoke-Funktionen wie GetMenu erreichbar sind. Ich hatte mir für die Vereinfachung der Fernsteuerung anderer Programme mal ein "Spionageprogramm" ähnlich Spy++ zusammengeschustert, mit dem ich dann auch z.B. notepad und dessen Menü auseinandernehmen kann. Aber weder die Menüstrips in meinen eigenen Programmen noch in neueren externen Programmen sind inzwischen damit erreichbar, da die dortigen Menus nur als allgemeines Fenster gehandelt werden. Ja, ich weiß, Windows heißt nicht umsonst so, schließlich sind alle CEs nur Fenster, aber ich kann diese Dinger einfach nicht näher analysieren, auch nicht mit Spy++ (aber mit Spy++ krieg ich noch nicht mal das notepad-Menü herangezogen):

    oben das Zielmenü, welches ich auslesen will, unten die "Analyse" (inkl. "Menüname = (keine)", keine Ahnung, ob das überhaupt was zu bedeuten hat)

    Das Zielmenü beinhaltet eine inhaltlich variable Anzeige eines Liefertermins. Wird die Lieferung abgesagt, ist der Text sehr kurz: "??"; gibt es einen Liefertermin, wird der angezeigte Bereich länger. Nein, nicht der MenuStrip wird breiter, sondern leider nur die Texte - an die ich aber nicht per P/Invoke rankomme. Das Textauslesen (SendMessage mit WM_GETTEXT) führt auch nur zu dem Namen "MenuStrip1", der zwar als Menübezeichnung hinterlegt ist, aber sonst nirgends gezeigt wird.

    Der Knackpunkt des Ganzen: Der (Nicht-)Liefertemin entscheidet über das weitere Vorgehen, daher muss ich ermitteln, was im gezeigten Menükopf steht.

    Inzwischen habe ich aus Verzweifelung zu dem Trick/Hack(?)/Workaround gegriffen, dass ich mir die Pixel anschaue und darauf schließe, was im Menükopf drin stehen könnte, aber wasserdicht finde ich das auch nicht.

    Hat noch jemand eine zündende Idee, die mir weiterhelfen könnte?

    Kleiner Nachtrag noch: Nein, eine Fensteranalyse des Menüs bringt auch nix, da sagt mir die Analyse, dass das gute Stück keine CEs beinhaltet.
    Nachtrag 2: Der Hersteller der externen Software ist nicht bereit mir diesbezüglich entgegenzukommen/zu helfen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „VaporiZed“ ()

    @VaporiZed Als ich hier dran gearbeitet hebe: Andere Programme fernsteuern
    fiel mir auf, dass .NET-Assemblies völlig anders reagieren, ich habe das dann auf diesem Weg aufgegeben.
    Ist das ein natives Programm oder eine Assembly?
    Einer Assembly könntest Du mit Reflection beikommen, wie beim IlSpy.
    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).
    VB-Fragen über PN / Konversation werden ignoriert!
    Es handelt sich leider um keine Assembly, sondern um ein natives, proprietäres Programm.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.