Panels verschachteln, bzw. gruppieren?

Hallo,

ich baue einen Stromkreissimulator. Durch Klicken auf einen Button füge ich ein Panel (Widerstand) dem Schaltplan hinzu. Anschließend soll man den Widerstand verschieben können.

Zu jedem Widerstand soll eine NumericUpDown-Box, ein Label und ein weiteres Panel für eine Grafik gehören.

Problem: Die Steuerelemente um den Widerstand sollen mit verschoben werden. Kann ich sowas wie ein Main-Panel machen, auf dem Label, weiteres Panel, etc. fest drauf verbunden ist? Oder gibt es vllt. bessere Möglichkeiten, das zu gruppieren?

Hi JohnnyKlaus,

ja, du kannst einem Panel weitere Unter-Elemente zuweisen, siehe Panel.Controls-Eigenschaft.

Christian

Hallo JohnnyKlaus,

es ist keine gute Idee, grafische Elemente als Controls zu realisieren. Schon ab 100 Controls auf einem Form kann es auf langsamen Rechnern zu Performance-Problemen kommen, ab mehreren 100 auch auf schnellen Rechnern.

Zeichne besser alles selbst. Das ist so schwer nun nicht, siehe [Tutorial] Zeichnen in Windows-Forms-Programmen (Paint/OnPaint, PictureBox) und [Tutorial] Gezeichnete Objekte mit der Maus verschieben.

herbivore

Hallo herbivore,

zu Deinem vorigen Post habe ich eine Frage.
Ich baue in Anwendungen gerne ein Masterpanel auf, in das mehrere Panels mit unterschiedlichen Controls darin eingebunden wird.
Über Button wird festgelegt welches Control im Masterpanel gerade aktiv ist.
Auf diese Weise können durchaus bis zu zwanzig Panel mit jeweils bis zu 20-30 Controls im MasterPanel enthalten sein. Das macht in Summe schnell mehrere hundert Controls in der einen (einzigen) Form.
Wäre es eventuell sinnvoller statt mehrerer Panel in einem MasterPanel mehrere Forms in einer MDI-Form unterzubringen?
Gibt es hierzu Richtlinien?

Viele Grüße,
telfa

es ist keine gute Idee, grafische Elemente als Controls zu realisieren. Schon ab 100 Controls auf einem Form kann es auf langsamen Rechnern zu Performance-Problemen kommen, ab mehreren 100 auch auf schnellen Rechnern.

Hm, ich denke es ist nicht das Problem, eine Textbos zu zeichnen, das Problem ist doch, die Funktionalität einer Textbox dann auch herzustellen...

Aus diesem Grund halte ich ehrlich gesagt nichts von deinem Argument. Ich habe hier Forms mit weit mehr als 500 Controls, diese laufen selbst auf einem 2,4 GHz Rechner unter Windows XP ohne Performanceprobleme.

Wobei hier eine Textbox noch eines der einfacheren Controls ist. Wie willst du dies mit einem Treeview oder einen DataGridview machen?

Stefan

Hi Stefan.Haegele,

es gibt für jedes Control einen spezifischen Renderer, den man auch verwenden kann, um eigene Controls mit Textboxen, Buttons usw. zu zeichnen. Mit TreeViews hab ich es allerdings noch nicht probiert.

Selbst Zeichnen ist die einzige Option, wenn man wirklich viele Controls auf einmal zeichnen muß. Ansonsten ist man wohl gut beraten, immer nur die Controls darzustellen, die auch tatsächlich sichtbar sind. Das dürften dann nur relativ wenige sein, also soviele, wie man auf den Bildschirm passen. D.h. man kann dafür z.B. virtuelle Listen o.ä. verwenden.

Christian

Also ich habe gerade ein Winforms Projekt in Arbeit, welches auch sehr dynamisch mit Controls handeln muß. Die Performance bei WinForms ist nicht wirklich gut geeignet für sowas.

Meine Aufgabe war/ist es, dynamisch eine GUI in einem fertigen System erstellen zu können und an bestimmte Datenfelder im Hintergrund zu binden. Hierbei hab ich einen Control-Editor geschrieben, mit dem man UserControls in xml-Format erstellen kann.

Auch hier können bestimmte UserControls, 100 male als Positionen vorkommen.

Es funktioniert alles tadellos, nur die Performance ist doch etwas mies für sowas.

Unter WPF ist es wesentlich besser, weil ja automatisch, je nach Leistungsanspruch, DirectX Unterstützung verwendet wird, soweit ich das verstanden habe.
Außerdem hat man vom Grafischen her viel mehr Möglichkeiten.

es gibt für jedes Control einen spezifischen Renderer, den man auch verwenden kann, um eigene Controls mit Textboxen, Buttons usw. zu zeichnen. Mit TreeViews hab ich es allerdings noch nicht probiert.

Hallo MrSparkle,

mir geht es nicht ums zeichnen, sondern um die Funktionalität eines Controls. Wie gesgat eine Textbox selbst zu zeichnen ist das eine, die Funktionalität dann dazu bereitzustellen eine andere...

Stefan

Hi ThomasE.,

Auch hier können bestimmte UserControls, 100 male als Positionen vorkommen.

Die können doch gar nicht alle gleichzeitig in einem Fenster sichtbar sein, oder? Dann sollte man auch nur die gerade sichtbaren Controls zeichnen lassen.

Unter WPF ist es wesentlich besser, weil ja automatisch, je nach Leistungsanspruch, DirectX Unterstützung verwendet wird, soweit ich das verstanden habe.

Solche pauschalen Aussagen würde ich nicht so stehen lassen. WPF ist moderner und verwendet tatsächlich DirectX statt GDI(+) zum rendern, aber das heißt noch lange nicht, daß Controls wesentlich performanter dargestellt werden können. Auch bei WPF ist man gut beraten, nicht gleichzeitig hunderte von Controls darstellen zu lassen.

Christian

Hallo telfa,

Wäre es eventuell sinnvoller statt mehrerer Panel in einem MasterPanel mehrere Forms in einer MDI-Form unterzubringen?

ich bin kein Fan von MDI.

Ich gehe mal davon aus, dass immer nur ein Panel mit 20-30 Controls sichtbar ist. Wenn man das Panel erst erzeugt, wenn es benötigt wird, und es zerstört, sobald man es nicht mehr braucht, hat man immer (ausreichend) wenige Controls auf dem Form.

Den Code zum Erzeugen der Panels/Controls gibt es eh. Ob man ihn nur ein für alle mal oder immer bei Bedarf aufruft, ändert den Codeumfang nicht (bzw. kaum).

Hallo Stefan.Haegele,

Hm, ich denke es ist nicht das Problem, eine Textbos zu zeichnen, das Problem ist doch, die Funktionalität einer Textbox dann auch herzustellen...

der Benutzer kann eh nur mit ein Control zur Zeit interagieren. Und das eine kann man als echtes Control auf das Form packen. Im konkreten Fall also immer nur die NumericUpDown-Box von dem angeklickten Widerstand. Für das reine Zeichnen der anderen Controls gibt es - wie von MrSparkle gesagt - passende Renderer.

Hallo ThomasE.,

nur die Performance ist doch etwas mies für sowas.

genau das meinte ich. Das zeigt eben auch, dass es in realen Anwendungen mit vielen Controls durchaus zu spürbaren Performance-Problemen kommen kann.

Ich würde drin zustimmen, dass WPF weit mehr Controls verkraftet als Windows Forms. Ob man deshalb nun zu WPF wechselt, muss jeder selber wissen.

herbivore

Aufruf der Suspendlayout und ResumeLayout Methoden der entsprechender ContainerControls, sollte die performance etwas verbessern, wenn gerade die sichtbarkeiten geändert werden.

Zu JonnyKlaus problem.
Wie wäre es wenn du so den Schaltkreis mit GDI+ zeichnest.
In einer Liste oder so hälst du dir die Koordinaten.
Und wenn mit der Maus auf eine bestimmte Koordinaten geklickt wird zeigst du dann erst entsprechend die benötigten Eingabe Controls laut deinem gewähltem/angekklicktem Objekt an.

Die könntest du ja auch wahlweise in einem extra Frame anzeigen und das angeklickt Objekt wird einfach etwas dicker gezeichnet zu Kennzeichnung das dieses selektiert ist.

Hallo Spyke,

Aufruf der Suspendlayout und ResumeLayout Methoden der entsprechender ContainerControls, sollte die performance etwas verbessern, wenn gerade die sichtbarkeiten geändert werden.

wenn die Anzahl der Controls zu groß wird, hilft bei Windows Forms leider alles nichts. Deshalb hatte ich auch einen Ausweichvorschlag (mit GDI+ und anklickbaren grafischen Objekten) gemacht, der sich genau mit deinem deckt.

herbivore

Sry, hat es durch das Rendern der std. Controls zuerst etwas anders verstanden.
Aber selbst die (nicht gebrauchten) std. Controls würde ich nicht mal nach Rendern, würde eh nur das Bild des Schaltkreises zerstörn, aber das nur meine Meinung am Rande.

Die können doch gar nicht alle gleichzeitig in einem Fenster sichtbar sein, oder? Dann sollte man auch nur die gerade sichtbaren Controls zeichnen lassen.

Dieses mußt du mir erklären, wie genau du das machen würdest ?
Das Erste was mir dazu einfiel, wäre alle nicht Sichtbaren Elemente den Visible-Status zu ändern.
Das Zweite wäre, im OnPaint eines Controls zu verhindern das es gezeichnet werden soll.

Solche pauschalen Aussagen würde ich nicht so stehen lassen. WPF ist moderner und verwendet tatsächlich DirectX statt GDI(+) zum rendern, aber das heißt noch lange nicht, daß Controls wesentlich performanter dargestellt werden können. Auch bei WPF ist man gut beraten, nicht gleichzeitig hunderte von Controls darstellen zu lassen.

Stimmt, tut mir leid, falsch ausgedrückt und mich zu wenig zurückerinnert. DirectX wird immer verwendet, nur werden automatisch je nach Gebrauch und DirectX Version, verschiedene Rendering-Ebenen verwendet :

Renderingebene 0 = 
                             (null) Keine Grafikhardwarebeschleunigung. Alle Grafikfeatures verwenden die Softwarebeschleunigung. Die DirectX-Versionsebene liegt in einer niedrigeren Version als 9.0 vor

Renderingebene 1 =
                             Einige Grafikfeatures verwenden die Grafikhardwarebeschleunigung. Die DirectX-Versionsebene beträgt mindestens Version 9.0
                
Renderingebene 2 = 
                             Die meisten Grafikfeatures verwenden die Grafikhardwarebeschleunigung. Die DirectX-Versionsebene beträgt mindestens Version 9.0

Wenn man normale Controls verwendet, kann es auch hier, nur wesentlich später als bei WinForms zu Performance-Problemen kommen.
In einem anderen großen Projekt von mir, werden unter WPF Firmen-Workflows abgebildet, nur machte ich dies nicht direkt mit Controls, sondern verwende eigene Klassen, die von FrameworkElement abgeleitet sind und zeichne alle benötigten Elemente mit DrawingVisual.

Mit dieser Methode funktioniert es, selbst bei einem 10000x10000 großen Canvas, recht performant.

Schon ab 100 Controls auf einem Form kann es auf langsamen Rechnern zu Performance-Problemen kommen, ab mehreren 100 auch auf schnellen Rechnern.

Jedes Control braucht ein oder mehrere Windows-Handles... diese sind beschränkt... und wenn alle verbraucht sind, dann läuft auf dem Rechner genau gar nichts mehr (nicht mal mehr eine Fehlermeldung... da diese auch ein Handle brauchen würde)... In diese Situation willst Du sicher nicht reintreten...

Hallo noch einmal,
dieser Gesichtspunkt ist schon sehr wichtig.
Was ich mich frage ist ob sich das bei WPF ähnlich verhält.

Viele Grüße,
telfa

Hallo ThomasE.,

Dieses mußt du mir erklären, wie genau du das machen würdest ?

ich würde das gar nicht machen, außer es gibt a) tatsächlich spürbare Performance-Probleme beim Zeichnen (wenn nicht gilt: "premature optimization is the root of all evil") und b) man bekommt die Berechnung, welche Teile gezeichnet werden müssen, selbst wesentlich effizienter hin als die Zeichenroutinen (z.B. DrawLine) hinbekommen. Die sind ja auch nicht blöd und zeichnen selber nur was nötig ist.

Hallo telfa,

ich gehe davon aus, dass etwaige Einschränkungen bei WPF wesentlich später zum Tragen kommen, wenn überhaupt.

Zum Beispiel ist die Schachtelung von Controls unter Windows Forms eher die Ausnahme (mal eine GroupBox, das war es meistens schon), unter WPF aber die Regel (z.B. eine TextArea und ein Bild auf einem Button). Insofern muss WPF zwangsläufig mit mehr Controls umgehen können.

EDIT: Natürlich gibt es unter Windows Forms die Möglichkeit, UserControls zu erstellen. Das war und ist mir bewusst. Das ändert aber nichts am Kern meiner Aussage.

herbivore

Zum Beispiel ist die Schachtelung von Controls unter Windows Forms eher die Ausnahme (mal eine GroupBox, das war es meistens schon)

Unter Winforms wird aber viel mit UserControls usw. gearbeitet... also ist auch da eine Schachtelung sehr gebräuchlich.

Gruss
Programmierhans

Ich weiß ja nicht wie andere da agieren, aber ich arbeite gerne mit Panels als Formersatz. Sollte mich wohl wieder mehr mit WPF beschäftigen...

Viele Grüße,
telfa

Jedes Control braucht ein oder mehrere Windows-Handles... diese sind beschränkt... und wenn alle verbraucht sind, dann läuft auf dem Rechner genau gar nichts mehr (nicht mal mehr eine Fehlermeldung... da diese auch ein Handle brauchen würde)... In diese Situation willst Du sicher nicht reintreten...

Also bis jetzt war ich noch nie in dieser Situation, selbst mit so vielen Controls..

Mal sehen, vielleicht wirds ja noch was 😃

Also bis jetzt war ich noch nie in dieser Situation, selbst mit so vielen Controls..

Dann kannst Du froh sein... war eine meiner Jugendsünden ... und echt übel da wieder rauszukommen.

Es hat hingehauen.
Vielen Dank an alle! 🙂

Hallo JohnnyKlaus,
ist doch interessant wie tief dieses reicht.
Solle man künftig in jedem Fall beachten.

Viele Ggrüße,
telfa