Fremdes Programm "bedienen", Informationen auslesen

[Sugar]

Hallo Forum,

Ich möchte gerne Informationen aus der Oberfläche eines fremden Programms auslesen und dieses Programm an anderer Stelle auch "Bedienen". Kurz mal zum Vorgang.

Das fremde Programm ist unser ERP System, dort kann ich eine Schaltfläche so konfigurieren, dass sie andere Programme - in dem Fall meins - startet. Mein Programm soll dann zwei bestimmte Editfelder auslesen.

Natürlich habe ich beim googeln etwas Code finden können, ich verstehe aber nicht ganz was an Angaben verlangt wird. In einem anderen unserer Projekte wurde mal etwas ähnliches umgesetzt, dort wurde der Inhalt eines "unserer" Editfelder an ein fremdes Programm gesendet.

Handle:=FindWindow('TBKMain', nil);
Handle2:=FindWindowex(Handle, 0, 'TBKClient', Nil);
postmessage(handle2,WM_PASTE,0,0); 

Meine Fragen nun: Handle:=FindWindow('TBKMain', nil)
Was ist das für ein Wert und wie erhalte ich den Wert der hier TBKMain lautet?
Wie ermittele ich unter den vielen Editfeldern des Fremdprogramms das Feld dessn Inhalt ich auslesen möchte?

Und in die andere Richtung, also von meiner Anwendung das ERP System bedienen: Ich möchte eine Suche starten - also einen bestimmten Button der Fremdanwendung "klicken" und im sich daraufhin öffenden Suchdialog wieder ein Editfeld ausfindig machen, füllen und einen weiteren Button klicken.

Ich wäre echt superhappy über Hilfe zu diesem Problem.

Gruß

[Christian Marquardt]

Was ist das für ein Wert und wie erhalte ich den Wert der hier TBKMain lautet?

TBKMain ist die Fensterklasse. Alternativ kann im 2. Parameter der Fenstername (Titel) vorgegeben werden. Die Klasse kann man mit div. Windowstools (WinSpy) ermitteln

Wie ermittele ich unter den vielen Editfeldern des Fremdprogramms das Feld dessn Inhalt ich auslesen möchte?

Ein Eingabefeld ist auch - wie alle Windowselemente - ein Fenster. Also mit FindWindow

Und in die andere Richtung, also von meiner Anwendung das ERP System bedienen: Ich möchte eine Suche starten - also einen bestimmten Button der Fremdanwendung "klicken" und im sich daraufhin öffenden Suchdialog wieder ein Editfeld ausfindig machen, füllen und einen weiteren Button klicken.

Fenster suchen, und mittels SendMessage entsprechende Botschaften senden

[Bernhard Geyer]

Die meisten ERP-System haben eine API mit der entsprechen alle gespeicherten Daten abgefragt werden können. Wieso jetzt versuchen so umständlich und fehleranfällig (gegenüber Änderungen der ERP-Gui) das realisieren?

[Sugar]

Erstmal Danke für den Hinweis an Christian. Ich probiere mal etwas rum und hoffe ich komme weiter.

Die meisten ERP-System haben eine API mit der entsprechen alle gespeicherten Daten abgefragt werden können. Wieso jetzt versuchen so umständlich und fehleranfällig (gegenüber Änderungen der ERP-Gui) das realisieren?

Das mag sein, allerdings fehlt in deiner Beschreibung ein wichtiges Attribut: "Die meisten 'ernstzunehmenden' ERP-System...". Ich frickele mich schon seit Monaten durch ein völlig verquanstes System das zwar eine MS SQL Datenbank benutzt, aber samtlichen Datenverkehr noch durch eine Access Datenbank schiebt. Die sind von API so weit weg wie unsere Sonne vom Tod.

Also, ich probier mal..

TBKMain ist die Fensterklasse. Alternativ kann im 2. Parameter der Fenstername (Titel) vorgegeben werden. Die Klasse kann man mit div. Windowstools (WinSpy) ermitteln

OK, ich hole mir als0 das Handle des Fensters über die FormCaption, richtig?

EDIT:

Ich habe nun mal gespielt. Folgender Code gibt mir schonmal ein Handle zurück (am Beispiel von Notepad)

var Handle: Hwnd;
begin
Handle := FindWindow(nil, 'Unbenannt - Editor');
if handle <> 0 then
ShowMessage('JA');
end;

Allerdings kann sich ja die FormCaption ständig ändern. In meinem Fall steht in der Form.Caption des ERP Systems immer auch die Projektnummer, also ständig etwas anderes.... Boah.... Krise krieg

Ein Eingabefeld ist auch - wie alle Windowselemente - ein Fenster. Also mit FindWindow

Ja, aber was? Wonach muss ich suchen? Muss ich den Komponentennamen des fremden Eingabefeldes kennen? Mit dem Code oben bekomme ich das Handle - Fall das ich den uneindeutgen Fenstertitel erkenne. Wie finde ich dann "mein" Eingabefeld?

[Christian Marquardt]

In meinem Fall steht in der Form.Caption des ERP Systems immer auch die Projektnummer

Ev. steht auch immer etwas festes drin (Programmname). Dann kann man prüfen, ob der String einen bestimmten Inhalt enthält (Notepad beginnt immer mit "Notepad")

http://www.marquardtnet.info/cecke/q...quicky_34.html

Besser wäre es die Fensterklasse zu ermitteln.

Ja, aber was? Wonach muss ich suchen? Muss ich den Komponentennamen des fremden Eingabefeldes kennen?

Komponenten sind ein Mittel der VCL, nicht von Windows.
Warum nutzt du nun nicht erstmal WinSpy um dir das anzusehen.

Des Weiteren gibt des für diese Problemstellung schon ein Haufen fertiger Programme

[Sugar]

Ev. steht auch immer etwas festes drin (Programmname). Dann kann man prüfen, ob der String einen bestimmten Inhalt enthält (Notepad beginnt immer mit "Notepad")

http://www.marquardtnet.info/cecke/q...quicky_34.html

Besser wäre es die Fensterklasse zu ermitteln.

Laut WinSpy lautet die Fensterklasse "Tapplikation" - davon laufen aber mehrere...

Des Weiteren gibt des für diese Problemstellung schon ein Haufen fertiger Programme

Die was tun?

[Christian Marquardt]

Die was tun?

Das was du machst. In Fenster Buttons klicken und Einträge vornehmen http://www.heise.de/download/auto-ma...r-1155627.html

Laut WinSpy lautet die Fensterklasse "Tapplikation" - davon laufen aber mehrere...

Dann musst du durchzählen. In welcher Position da was einzutragen ist. Es gibt doch eine feste Baumhierarchie

[Bernhard Geyer]

..., aber samtlichen Datenverkehr noch durch eine Access Datenbank schiebt. ...

Mein Beileid. Ein ähnlich vermurkstes System hatten wird vor einiger Zeit auch noch

[Sugar]

Zunächst einmal Danke für die Hinweise, ich bin ein ganzes Stück weiter. Aber nicht am Ziel....

Mit WINSPY (der erzeugt ja sogar Delphi-Code!) habe ich mich durchgehangelt, etwas gelernt und mich wenigestens ein Wochendende vor den PC gefesselt.

Ich bekommen nun aber Probleme. Die Anwendung die ich ein Stück weit "bedienen" möchte ist ergonomisch etwas (für mich) ungewöhnlich aufgebaut. Aus dem Hauptfenster kan ich nach Projekten (Aufträgen) suchen indem ich auf einer TOOLBAR den berühmten gelben offenen Ordner anklicke. WinSpy gibt aber nur das Handle der ToolBar, nicht des einzelnen Buttons zurück. Das umgehe ich, indem ich simpel über das "MainMenu" den Suchdialog starte.

Das folgende Fenster
Unbenannt.jpg


(das hier ist nur ein Beispiel, nicht das entsprechende Fenster)

hat aber links eine Navigationsoberfläche, von der ich keine Handles der Labels bekomme, die ich eigentlich fernsteuern möchte. Ich kann dort zwar (in diesem Bild nicht ersichtliches) Eingebafeld beschreiben, aber ein "Enter" übernimmt die Selektion auch innerhalb des Programms nicht. Ich muss - in der Originalumgebung - entweder eines der Labels auf der Navigationsleiste klicken, oder den RowIndicator(!) des Grids. Selbst ein Doppelklick auf das Grid übernimmt bzw. öffnet das Projekt nicht innerhalb der nativen Software.

Kurz: Ich kann zwaz von extern die Suche zum gewünschten Ergebnis bringen, scheitere aber daran das entsprechende Label auf der Navigationskomponente zu identifizieren, bzw. den RowIdicator des selektierten Datensatzes in dem Grid.

Gibts da Hinweise?

Und mal ehrlich.. ist so eine Entwicklung State of The Art, oder nur hirnrissige Spielerei? Das System, das ich etwas steuern will, sollte ein ERP System sein das wenigstens etwas Ergonomie aufweist....

[Christian Marquardt]

Ich kann nicht erkennen, was nun Ergonomie mit deinem Problem der Ansteuerung zu tun hat. Im allgemeinen sind solche Versuche eher sinnlos; bei Änderungen muss man nachziehen und das alles meistens nur um 2 Klicks zu sparen.
Des Weiteren ist das kein Thema für Programmieranfänger.
Üblicherweise haben solche Systeme dann eine API die den Zugriff erlauben und man muss nicht über solche Krücken gehen

[Ralf Jansen]

Wenn du kein Handle für das Control findest ist es eben kein Control. Es muss kein Label sondern ist einfach gezeichneter Text und jedes Toolbar Control das ich kenne zeichnet seine Buttons selber. Nichts hindert einen Programmierer daran das selbst zu machen und irgendein verhalten zu simulieren. Das ist oftmals nicht mal schlechter Stil, Handles sind ja ein begrenzte Resource. Und kein Programmierer (inbesondere bei einer Inhouse LOB Anwendung, das ist doch nix von der Stange?) wird sich Gedanken darüber machen etwas zu machen wofür nicht bezahlt wird. Oder es einem Hacker leicht zu machen und nichts anderes als hacken ist das gerade was du tust.

Wenn du eine API brauchst beauftrage den Author der Software bzw. den Besitzer des Source-Codes damit. Was du gerade tust ist voraussichtlich nicht billiger und schon gar nicht nachhaltiger.

[Sugar]

Das ist Hacken? Blödsinn, ob nun ein Mensch oder eine Maschine die Buttons klickt, es bleiben angebotene Funktionen und erlaubte Bedienung.

Im Übrigen versuche ich lediglich, ein System das eben nicht über APIs verfügt, ein wenig integrationsfähiger zu machen. Das der Weg nich nachhaltig ist bestreite ich ja gar nicht.

[Ralf Jansen]

Das ist Hacken? Blödsinn, ob nun ein Mensch oder eine Maschine die Buttons klickt, es bleiben angebotene Funktionen und erlaubte Bedienung.

Welche angebotenen Funktionen bietet den das Programm den Button zu klicken? Der kann irgendwie implementiert sein. Wenn es ein Button aus den Common Controls kannst du Glück haben und der Standard weg mit Windows Messages oder Accessability API funktioniert. Nichts hindert aber einen Programmierer das Verhalten selbst zu implementieren oder das Verhalten des Common Control Buttons nach seinem Geschmack zu ändern. Letztlich ist derjenige der eine Funktion ohne API über eine GUI auslösen will darauf angewiesen durch irgendwelche Methoden (das ist hacken) rauszufinden was den intern passiert um dann von außen einen Weg zu finden das auszulösen.

[Sugar]

Welche angebotenen Funktionen bietet den das Programm den Button zu klicken? Der kann irgendwie implementiert sein. Wenn es ein Button aus den Common Controls kannst du Glück haben und der Standard weg mit Windows Messages oder Accessability API funktioniert. Nichts hindert aber einen Programmierer das Verhalten selbst zu implementieren oder das Verhalten des Common Control Buttons nach seinem Geschmack zu ändern. Letztlich ist derjenige der eine Funktion ohne API über eine GUI auslösen will darauf angewiesen durch irgendwelche Methoden (das ist hacken) rauszufinden was den intern passiert um dann von außen einen Weg zu finden das auszulösen.

Das ist doch Wortklauberei! Eine Schaltfläche, die ohnehin frei verfügbar ist, maschinell zu bedienen ist keinesfalls hacken. Hacken wäre es, wäre der Button durch Benutzerrechte nicht verfügbar (unsichtbar) und ich wüde ihn maschinell bedienen.

Im Übrigen habe ich eine Lösung gefunden. Ich konnte scannen, dass hinter den Toolbar-Buttons jeweils Makros stehen die ich sehr gut erkennen und aufrufen kann.

Irgendewie wie API...

[tömmel]

Wat'n Murks!

Natürlich baust du für irgendwelche Leute nich noch kompfortable hintertüren ein, damit sie die Applikation du maßgeschneidert hast hnterher übernehmen können und daran herumschrauben!

Wenn das ERP - So scheiße ist, dann ersetz es doch!

Und nebenbei : Hast du die Quellen?
Nein?
Dann frag dich doch mal warum!