Übergabe von Parametern vom Element an AddInFramework C#

[zero]

Hallo,

ich habe in meinem Zenon Projekt viel mit VBA gearbeitet. Wir wollen aus vielen Gründen jetzt von VBA weg.
Deshalb habe ich begonnen meine Skripte ins Add-In Framework (C#) um zu ziehen.
Jetzt stehe ich vor dem Problem, das ich viele Makros habe die mit Informationen des Elementes arbeiten, von dem sie aufgerufen wurden.
z.B. mit einem Klick auf den Zahlenwert einer Temperatur, soll eine Trendseite aufgerufen werden und die dargestellte Variable soll dynamisch durch die Variable
ersetzt werden, welche in im angeklickten Element verknüpft ist.
Ich weiß, dass es für diesen Anwendungsfall mittlerweile auch eine Lösung ohne Programmierschnittstelle gibt, aber dies ist nur ein Beispiel von vielen, bei dem ich Informationen welche ein Element enthält zur weiteren Verarbeitung nutze.
Auch vermisse ich die Möglichkeiten von MouseOver, Rechtsklick, Doppelklick etc. wie geht Ihr hier im AddIn Framework damit um?

Gruß Tobias

[zero]

wenig los bei meinen Fragen
Aber nach einigen Wochen habe ich jetzt einen einigermaßen gangbaren Weg gefunden. Wäre toll, wenn sich noch was effizienteres finden lässt...
Also nochmal, wie umgeht ihr das Problem, dass man im AddIn Framework eigentlich keine Infos zum auslösenden Element erhält, weil das AddIn Skript meist per Funktion angestartet wird?

Ich bin jetzt den Weg über einen Service gegangen. 
Als erstes checke ich mal alle Events ein.
Der Runtimeservice überwacht alle klassischen Eingaben z.B. LeftClick, RightClick, MoiseOver etc.

 public void Start(IProject context, IBehavior behavior)
        {
            myProject = context;
            myProject.ScreenCollection.ElementMouseOver += ScreenCollection_ElementMouseOver;
            myProject.ScreenCollection.ElementLeftButtonUp += ScreenCollection_ElementLeftButtonUp;
            myProject.ScreenCollection.ElementRightButtonUp += ScreenCollection_ElementRightButtonUp;            ...
        }

Wird eine dieser Aktionen ausgelöst stehen mir wie in VBA die Element Informationen zur Verfügung von dem Element auf dem die Aktion ausgelöst wurde.
Aufgrund von dem Elementnamen starte ich dann meine entsprechendes Skript (z.B. Trendansicht einer Temperatur) in einem eigenen Thread.

private void ScreenCollection_ElementLeftButtonUp(object sender, Scada.AddIn.Contracts.Screen.ElementLeftButtonUpEventArgs e)
        {
                        
            Element = e.Element;
            TreadContainer MyTread = new TreadContainer(myProject, Element);
            //Event für Tempsensor Trendansicht###############################################################
            if (Element.Name.Contains("TempSensor"))
            {
                Thread T1 = new Thread(MyTread.TempsensorTrend);
                T1.Start();
            }
            //Event für sämtliche Trendansichten von Energieverbräuchen###############################################################
           ...

aktuell steht so alles untereinander die Events, die Skriptauswahl und dann die jeweilige Skripte selbst.
Wir auf die Dauer etwas unübersichtlich...

[felixst]

Hallo Tobias,

was genau findest du daran unübersichtlich?
Du hast einen Service der auf Events reagiert und abhängig vom übergebenen Objekt unterschiedliche Programmverläufe abarbeitet. Und je variantenreicher das Ganze ist, desto mehr Code ist nötig. Mehr Code ist zwar irgendwie schon unübersichtlicher als weniger. aber es gibt ja unterschiedliche Möglichkeiten Code zu strukturieren und mithilfe von IDEs die Übersicht zu behalten.
Welche IDE verwendest Du?

Auf die Schnelle fielen mir als Varianten noch ein, für jedes Event (MouseOver, LeftClick, ...) einen eigenen Service zu schreiben. Dann wäre es aufgeteilt auf verschiede AddIns. Fraglich ist, ob es dadurch übersichtlicher wird?
Du könntest auch die Kaskade von If-Abfragen durch ein Switch-Statement ersetzen. Das macht prinzipiell das Selbe, machen finden es aber leichter lesbar.
Noch eine Variante wäre, den Code, so wie er ist mit Regionen (#region) zu strukturieren.

Das alles ist aber in meinen Augen eher eine programmierphilosphische Diskussion und hat weniger etwas mit unserem Produkt an sich zu tun.

Was wird denn in den Eventroutinen im Detail gemacht? Wenn da recht viele Zugriffe auf die zenon API vorkommen, oder es ohnehin schnell geht, könnte man sich den Aufwand mit den Threads ggf. auch sparen.

Schöne Grüße aus Salzburg,
Felix