UserControls in Panel ansprechen (Ablauf-Baukasten)

Moin,

ich bastel gerade ein wenig bezüglich "grafischer Funktionsbaukasten" (wie ein Node-Editor in Anfängerversion :tongue🙂 rum und stoße ein paar Probleme:

Was es werden soll, erläutere ich mal anhand eines Beispiels:

Ich habe beispielsweise zwei eingebaut Funktionen im Programm:

Funktion 1: Zähle rote Pixel in Bild
Funktion 2: Zähle grüne Pixel in Bild

Außerdem die Eingabe:

Eingabe 1: Es sollen nur 50 farbige Pixel im Bild sein.

Und die Ausgabe mit Option:

Ausgabe 1: Textbox, Option: Schriftgröße

Jetzt habe ich vier Steuerelemente erstellt:

• Zähl-Element: Farbe wählbar
• Soll-Element: Anzahl eintragbar
• Vergleichs-Element: 2 Inputs-Wählbar
• Ausgabe-Element: Textgröße eintragbar

Die Elemente sollen in ein Panel gepackt und verknüpft werden können, und die so entstehende Wunsch-Funktion soll speicherbar sein.

Jetzt ist mir aufgefallen, dass ich nicht per "panel1.Controls.SollElement.Width" oder so auf die Elemente zugreifen kann.

Es geht nur z.B. "panel1.Controls.Find("SollElement", true/false)_.Width für das direkte Element.

Und scheinbar auch nur mit "panel1.Controls.Find(TextBox_Sollwert", true)_.Text für Unterelemente?

Aber wenn ich jetzt ein CustomElement mehrfach in das Panel Adde heißen die Unterelemente darin ja immer gleich 😐

Hat jemand einen Tip was man da machen kann?

(Oder gibt es da was fertiges hüstel)

Kannst du nicht einfach mit die Steuerelemente mit einer count-Variable versehen?

"TextBox_ "+ count

Und dann könntest du diese noch in eine Liste speichern, wenn es dir Vorteile bringt.

EDIT: Erstellst du die CustomElemente per Code oder manuell?

Gruß

Ich bau die von Hand.

Die CustomElemente selbst könnte ich nummerieren, aber die Elemente der Elemente heißen dann gleich.
Und nach denen müsste ich ja suchen 😐

Sind die "CustomElemente" UserControls die wiederum Controls enthalten? Möchtest Du auf die Controls zugreifen die in den UserControls enthalten sind?

Genau.

Panel.Controls.CustomControl.Button1.Text quasi.

Erstell dir dafür lieber eigene Eigenschaften im UserControl.

Warum sollte man von außen auf alles beim Button zugreifen wollen?
Oft sind doch nur das Clicked-Event oder der Text interessant.

Du kannst den Modifier der Controls in dem UserControl auf Public setzen. Das ist meiner Meinung nach aber schlechter Stil. Du solltest lieber entsprechende Eigenschaften im UserControl anlegen, die die benötigten Eigenschaften der enthaltenen Controls durchreichen (wie pinki es geschrieben hat).

Ok, das ist wohl wahr.

Aber wenn ich es aus meinem "CustomControl1" nach außen reiche und dann zwei "CustomControl1" erstelle, heißen die Controls, oder was auch immer, in dem CustomControl ja dennoch gleich.

Oder kann ich beim Erstellen von außen eine Benennung für ein Element im CustomControl angeben?

Ich glaube nicht, aber das weiß ich nicht zu 100%.

aber wenn die Elemente in dem CustomControl eineindeutig sind und das CustomControl auch, dann kannst du doch nach dem CustomControl suchen und von dort auf die inneren Controls zugreifen.

Aber wenn ich es aus meinem "CustomControl1" nach außen reiche und dann zwei "CustomControl1" erstelle, heißen die Controls, oder was auch immer, in dem CustomControl ja dennoch gleich.

Was willst Du denn genau machen? Warum sollen die Controls innerhalb der UserControls in der gesamten Form eindeutige Namen haben?

Was willst Du denn genau machen?

Die Anordnung der UserControls soll die Reihenfolge der Ausführung vorgeben und der Inhalt z.B. einer TextBox in einem UserControl würde einen Paramter enthalten.
Die jeweiligen Ausgaben würden nach unten hin durchgereicht werden.

*siehe Paint-Bild im Anhang*

Warum sollen die Controls innerhalb der UserControls in der gesamten Form eindeutige Namen haben?

Wenn jetzt zwei mal das gleiche UserControl-Element hinzugefügt wird und ich die Elemente nur mit panel.Controls.Find(Name,true)_ finde, würde ich ja mehrere Treffer erhalten.

Du solltest mehr mit Eigenschaften und Events arbeiten anstatt mit der Suche nach Steuercontrols, dann ersparst dir das Problem, eben so wie @pinki geschrieben hatte.

Control->Event->Property setzen->wenn notwendig eigenes Event aufrufen daß sich ein Wert verändert hat

Somit hast du im Main dann immer Events von dir wenn sich Daten in bei den Feldern in den UserControls geändert haben, ohne nach den Steuerelementen suchen zu müssen...

Ok, thx.

Werde ich mir ansehen! =)

Unabhängig davon, dass an dieser Stelle die Events vermutlich sinnvoller wären, könntest du aber den Panels noch das Tag-Attribute geben um diese zu differenzieren... Dann könntest du alle gefundenen Controls durchlaufen und auf das Tag prüfen... in etwa so:

Panel pan;
Control[] c = this.Controls.Find("PanelText", true);//So richtig? Verwende den gar nicht..
foreach(Control match in c){
  if(match.Tag.Equal("mein Suchobjekt"){//Eventuell noch ein Tag.ToString().Equal(...) draus machen
    pan = (Panel)match;
    break;
  }
}

Wobei ich das jetzt nicht getestet habe...

Gruß Frokuss

Hi Gimmick,

Die Anordnung der UserControls soll die Reihenfolge der Ausführung vorgeben

Das klingt, als würdest du die Benutzeroberfläche als Anwendungslogik "mißbrauchen". Eigentlich sollte es so sein, daß dein Model die Logik (Reihenfolge etc.) abbildet, und die UI gezeichnet wird, um das Model zu grafisch repräsentieren. Siehe dazu evtl. auch [Artikel] Drei-Schichten-Architektur

Solche "Node-Editoren" gibt es ja auch schon als OpenSource im Netz. Da könntest du dir anschauen, wie es andere vor dir gelöst haben, und dich inspirieren lassen.

in etwa so:

Panel pan;  
Control[] c = this.Controls.Find("PanelText", true);//So richtig? Verwende den gar nicht..  
foreach(Control match in c){  
  if(match.Tag.Equal("mein Suchobjekt"){//Eventuell noch ein Tag.ToString().Equal(...) draus machen  
    pan = (Panel)match;  
    break;  
  }  
}  

Wobei ich das jetzt nicht getestet habe...

Gruß Frokuss

Ich müsste wahrscheinlich sowohl beim "Tag", als auch beim "Name" alle Controls innerhalb des UserControls beim Erstellungsaufruf durchnummerieren.
Also schauen: Wie oft gibt es das UserControl schon?
-> Das UserControl und alle Unter-Controls suchen und benennen.

Da man die Dinger ja auch wieder entfernen kann wird das glaube ich nicht unbedingt wenig arbeit und übersichtlich. Aber müsste ja gehen.

Die Anordnung der UserControls soll die Reihenfolge der Ausführung vorgeben

Das klingt, als würdest du die Benutzeroberfläche als Anwendungslogik "mißbrauchen". Eigentlich sollte es so sein, daß dein Model die Logik (Reihenfolge etc.) abbildet, und die UI gezeichnet wird, um das Model zu grafisch repräsentieren. Siehe dazu evtl. auch
>

Naja, eine Texteingabe "wie oft soll die schleife berechnet werden" ändert ja so gesehen auch die Logik.
Es werden ja keine Funktionen/Methoden generiert, es geht ja quasi nur um die Aufrufe - eine interaktivere (wenn es gut geht) Variante von Comboboxen quasi.

Nach NodeEditoren habe ich schon gesucht. Dass ist auch irgendwann mal das Ziel, aber den Aufwand für die Grafiken, hübschen Verknüpfungen etc. will ich mir erstmal sparen.
Ich versuch das erstmal nach dem Steckkastenprinzip. ^^

Ich müsste wahrscheinlich sowohl beim "Tag", als auch beim "Name" alle Controls innerhalb des UserControls beim Erstellungsaufruf durchnummerieren.
Also schauen: Wie oft gibt es das UserControl schon?
-> Das UserControl und alle Unter-Controls suchen und benennen.

Da man die Dinger ja auch wieder entfernen kann wird das glaube ich nicht unbedingt wenig arbeit und übersichtlich. Aber müsste ja gehen.

Genau diese umständliche Vorgehensweise könntest du dir ersparen, wenn du dir erstmal ein Model und eine Business-Logik erstellst. Dann kannst du geeignete Datenstrukturen verwenden, kannst alle Funktionen mit Unit-Tests testen und sicherstellen, daß alles so funktioniert wie gewünscht.

Die UI ist dann lediglich eine grafische Representation deiner Daten und wird nur dann neu gezeichnet, wenn sich dein Model geändert hat. Die Vorteile dieser Herangehensweise sind ja in dem verlinkten Artikel aufgeführt, und es gibt eigentlich keinen Grund, das alles auf Biegen und Brechen in der UI zu implementieren.