Laden...

Schnittstelle zur Fernsteuerung der eigenen Applikation erstellen

Erstellt von christof.k vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.681 Views
C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren
Schnittstelle zur Fernsteuerung der eigenen Applikation erstellen

Hallo,

ich habe eine Applikation geschrieben, welche auf den CAN-Bus verschiedene Nachrichten ablegt und die über das eigene GUI gesteuert wird.

Für eine Testautomatisierung benötigen wir eine Schnittstelle, welche meine Applikation fernsteuert.
Im Moment wird das über Excel-VBS und SendMessage gemacht, welche den User "simultiert". Dies funktioniert nur bedingt gut, da z.B. spezielle Usercontrols so nicht erreichbar sind. Außerdem darf ich keine meiner GUI-Elemente umbennen, da ansonsten das Excel-Makro auch angepasst werden muss.

Eine Google- und Forumsuche hat leider nur Ergebnisse gebracht, wie man andere Anwendungen steuert. Ich würde lieber eine einfache aber effiziente Art in meine Applikation einbinden, so dass die Fernsteuerung vereinfacht und generisch wird.

Ich habe von Möglichkeiten gehört, auf User-Messages zu reagieren, doch fehlt mir da noch etwas Info.

Über einen Tip, wie ich möglichst schnell so ein Interface realisieren kann und Excel weiterhin als Fernsteuertool nutzen kann, wäre ich sehr dankbar.

Vielen Dank
Christof

Gelöschter Account
vor 13 Jahren

Dein Vorhaben nennt sich UiTesting. Dafür gibt es bereits einiges auch kostenloses.

Excel weiterhin als Fernsteuertool nutzen

Das allerdings würde ich dir nicht empfehlen. Das grässlich und sozusagen "von hinten durch die Brust" und du wirst mit dieser Lösung niemals glücklich werden.

C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren

Das Problem ist, das das Testen sich nicht auf meine Applikation bezieht, sondern auf das Steuergerät, was am CAN Bus hängt. Meine Applikation ist sozusagen nur der "Stimulator". D.h. ich will nicht meine GUI testen sondern diese nur fernsteuern.

Excel ist sozusagen das Bindeglied und steuert meine Applikation und wertet Daten aus dem Steuergerät aus. Final wertet das Excel Skript dann die Ergebnisse aus.
Diese läuft zufriedenstellend (wenn da nicht das Fernsteuerproblem wäre 😉)

Danke
Christof

Gelöschter Account
vor 13 Jahren

wenn du das Steuergerät testen willst, dann schreibe einen Unittest. Der Weg über die Oberfläche birgt nur Unsicherheiten.

Excel ist sozusagen das Bindeglied und steuert meine Applikation und wertet Daten aus dem Steuergerät aus

Wie darf man sich das vorstellen? Mir scheint, das hier ein ambitionierter VBA Entwickler am Werk war, der Excel als Laufzeitumgebung für normale Anwendungen missbraucht?

C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren

Hi,

Unser Messtool für die Kommunikation hat eine COMM-Schnittstelle, welche über Excel angesprochen wird.
Mein Tool sendet nur die richtigen Nachrichten zur rechten Zeit über den CAN-Bus.
Diese Messungen werden dann vom Excel-VBS ausgewertet.

Wie würden gerne bei Excel bleiben, da damit auch nicht C#-Kenner umgehen können. Das Skript im Hintergrund wertet die Excel-Tabelle aus, die in sich Zeilenweise die Tests definiert.
Ich weiß, es gibt da weit aus elegantere Lösungen, aber diese hat sich etabliert und ich benötige sonst ein kostenloses, "relativ" leicht wartbares tool.

Deshalb würde ich gerne im ersten Schritt gerne eine Möglichkeit haben, meine Funktion von Excel über fernzusteuern. Da das mit den Windows Nachrichten schon prinzipell klappt frage ich mich, wie man diese so selbst definieren kann, dass ich die in meiner C# Applikation auswerten kann.

Aber wie gesagt, elegantere (aber im ersten Schritt durch Excel nutzbare) Lösungen sind herzlich willkommen.

Danke
Christof

Gelöschter Account
vor 13 Jahren

Unser Messtool für die Kommunikation hat eine COMM-Schnittstelle, welche über Excel angesprochen wird.

COM kann man auch aus C# heraus aufrufen.

Wie würden gerne bei Excel bleiben, da damit auch nicht C#-Kenner umgehen können.

Das ist ein Grundsatzproblem der Excel-denke. Ich frage mich immer wieder, woher die Annahme kommt, das nur weil etwas in Excel gemacht ist, das jedermann automatisch keine Kenntnisse vom System haben muss, um damit umgehen zu können....

Fakt 1 ist: Ohne VBA kann man sowieso nichts einschneidendes ändern. Also muss man programmieren können.
Fakt 2 ist: Es geht eigentlich nur um die TestDaten und um die Testkonfiguration, welche in den Tabellen gehalten werden. Diese kann man relativ einfach in Excel anpassen ABER man muss dennoch immer genau wissen was man da macht und was man nicht machen darf.

Daher könnte man ebensogut XML, CSV oder was auch immer und ein schönes C# programm nehmen, ohne auch nur 1% der effektivität einbüßen zu müssen.
Des weiteren kann man die Testconfig auch nach belieben direkt aus dem Excel aus C# heraus auslesen und verwenden. Daher besteht keinerlei vorteil, sondern eher ein Nachteil, wen nman sich den Weg mit VBA zusammenfrickelt...

so.. genug davon ^^

Für dein Vorhaben sehe ich Prinzipiell 2 Wege.

  1. Du stellst die wesentlichen Funktionen deiner Applikation auch als COM zur Verfügung. Dann kann das VBA Makro zur rechten zeit deine Methoden aufrufen und alles in gang bringen.

  2. Du kannst dich auch als Excel Addin programmieren und dich so reinhängen... Dann könnte das Makro deine Funktionen auch so aufrufen.

genaueres kann ich dir aber nicht nennen, da ich die Aufruffolge und die Abhängigkeiten nicht kenne.

H
15 Beiträge seit 2008
vor 13 Jahren

Hallo,

ich verstehe im Mom auch noch nicht so ganz warum das unbedingt über excel laufen muss, ich will dich hier aber nicht zum C# überreden, vielleicht eher im gegenteil...
Ich habe mal ein zwei kleinere GUI-Automationen in C# mittels des white-frameworks geschrieben, und man kann viel damit machen (sofern sich die Steuerelemente in UISpy oder, ähnlichem iidentifizieren lassen).
Jedoch hat es mich pro applikation so ca. 2-3Wochen gekostet. Das war im endeffekt viel aufwand fuer eine wiederkehrende, aber auch bedingte Sequenz von "Knöpfedruecken". Das lag an der grossen Fehlerbahndlung, die Nötig war, wenn sich die GUI anders verhielt als sie im normalfall sollte.

Ich weiss nun nicht, wieviel zeit du hast, bzw wie -anfaellig- die GUI fuer ungeahntes verhalten ist... aber sollte deine GUI irgendwie Messages aus dem CAN auswerten, kann ich mir das gut vorstellen
Aber wenn es dich interessiert, such mal nach dem White-framework (evtl. in verbindung mit nUnit). ansonsten bleibe lieber bei einer Schnittstelle "unterhalb" der GUI, um deine Funktionen automatisiert aufzurufen...

Eine andere etwas -skurile- lösung fuer GUI-automation ist "Sikuli" welches irgendwie über die Farbwerte des Monitorbildes geht oder so, und dort einfach die Maus draufklicken laesst.
Dies ist wesentlich einfacher zu "programmieren" wenn man es ueberhaupt so nennen darf, aber auch nicht sehr -intelligent- was das verhalten angeht.

musst du mal schauen...
ich hoffe ich konnte dir helfen

C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren

Hi,

danke für den Tip.

Eigentlich suche ich auch eine Möglichkeit, "unter" der GUI zu bleiben, also z.B. auf custom user messages zu reagieren.
An COMM traue ich mich nicht ganz ran, da ich da jede Menge Arbeit erwarte.

Ich dachte an eine Lösung wie z.B. jeder Funktion meines Programmes eine ID zu geben und dann kann jemand eine message an mein Programm schicken (wie auch immer) und zu der ID den Wert des Signals angeben. Und schon wäre die Fernsteuerung fertig. Den Umweg über die GUI finde ich auch eher "unelegant".

Als nächstes schaue ich mir mal Deine Vorschläge an, aber falls Du noch einen Tip hast, immer her damit.

Danke
Christof

Gelöschter Account
vor 13 Jahren

Eigentlich suche ich auch eine Möglichkeit, "unter" der GUI zu bleiben, also z.B. auf custom user messages zu reagieren

nein nein... tiefer musst du gehen.

Es ist so: Du brauchst nur deine BL. Sonst nichts. Daher reicht es eigentlich, wenn du deine BL aufrufen könntest und das kannst du schon recht einfach mit z.b. übergabeparameter an deine exe oder named pipes oder alles andere was unter die Kategorie "IPC" (Inter Process Communication) fällt.

Möglich wäre sogar, das dein Programm auf gewisse Felder der Excel horcht oder innerhalb von Excel einen Callback anbietet...

Es gibt hier viele Möglichkeiten, die alle besser sind, wie die GUI fernzusteuern.

C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren

Hi,

vielen Dank für die fruchtbare Diskussion. Ich denke ich habe noch den Designfehler, dass ich meine Low-Level Ebene zu stark an die GUI gekoppelt habe. War am Anfang nicht davon ausgegangen, Automatisierung je zu brauchen.
Ich denke das werde ich auflösen und dann Deinen Tip zum Thema IPC aufnehmen.
Das Thema named pipes gefällt mir, da es völlig Sprachunabhängig ist. Dass sollte Excel auch hinkriegen, oder?
A propos: Wofür steht "BL"?

Vielen Dank!

Christof

1.002 Beiträge seit 2007
vor 13 Jahren

Hallo christof.k,

A propos: Wofür steht "BL"?

BL steht für Business Layer. Das ist klassischerweise die Schicht einer Anwendung, die unterhalb des GUI, aber oberhalb des DAL (Data Access Layer) angelegt ist. Diese kümmert sich um die eigentliche Anwendungslogik, die sauber vom Datenzugriff und der Anzeige getrennt ist.

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

F
240 Beiträge seit 2006
vor 13 Jahren

Wobei die Trennung bei ihm wohl nicht ganz der Fall ist 😉

Hinweis von herbivore vor 13 Jahren

Nach der letzten Aussage christof.k soll sich das aber gerade ändern.

Gelöschter Account
vor 13 Jahren

Multithreaded named pipe problems
Hier hat der Threadersteller zwar Probleme aber das bezieht sich auf das Threading. Wenn du das weglässt, hast du einen Beispielcode, wie man aus VBA Named Pipes verwenden kann.

Ich denke ich habe noch den Designfehler, dass ich meine Low-Level Ebene zu stark an die GUI gekoppelt habe.

^^
Ja, jetzt hast du gelernt, wozu Entkoppelung wichtig ist 😃
Diese Erkenntnis ist enorm wertvoll.

C
christof.k Themenstarter:in
159 Beiträge seit 2005
vor 13 Jahren

Das Problem (ich hoffe ich bin da nicht allein) ist, das manche Projekte als "Hobby" anfangen, d.h. man hat nie richtig dafür Zeit, ist froh wenn es dann läuft. Dann wächst so ein Projekt und eh man sich versieht, wird es Unternehmensweit eingesetzt und man traut sich nie, den Sourcecode weiterzugeben, da es sonst peinlich wird.

In Zukunft werde ich da ein größeres Augenmerk drauf legen.

Vielen Dank für den Top Support in diesem Forum!
Christof