Event bei Z-Order Änderung o.ä.

[Bummi]

ich will ja nicht unken, aber ich bin immer noch der Meinung dass es sinnvoller wäre alles in einer Komponente abzufackeln, Alignments, Ausrichtungen und Längen lassen sich ja auch berechnen.

[Medium]

Nicht, wenn die Breite der Skalentexte zur Runtime erst bekannt wird. Dann ist das Control längst platziert, und ich will im Code des eigentlichen Projektes keine Fetzen rumfliegen haben, die die Neuausrichtung machen müssen. Zudem ist es so auch noch etwas gefälliger im Umgang im Designer, da der ja doch recht große Freiraum zwischen den Skalentexten nicht mehr zum Balken gehört, und man die nicht mehr so oft aus Versehen erwischt, wenn man eigentlich ein anderes in der näheren Umgebung haben wollte. Für unsere Zwecke erscheint mir das zunächst als guter Weg, es sei denn da hat noch jemand konkrete Killer-Argumente die ich bisher nicht bedacht habe.

[Sir Rufo]

Ich mag TLabeledEdit nicht, weil es sich völlig anders verhält als andere Controls.

Es beansprucht mehr Platz als es die Abfrage (Width,Height) vermuten lässt.
Align ist auch nicht sinnvoll möglich.

Es ist also ein Konstrukt, was den Benutzer in einigen Punkten überrascht, und solche Ü-Eier gelten im Allgemeinen als schlechter Code.

Einen Vorteil kann ich da auch nicht entdecken, nur Faulheit.

Es geht nicht darum, dass eine Komponente TLabeledEdit unnütz ist, sondern darum, dass diese schlecht implementiert ist. Die Gründe dafür sind mir egal weil man sich alles schönreden kann.

[Medium]

Nun, da das Teil nur für einen sehr speziellen Zweck eingesetzt wird (Prozessvisualisierung, ähnlich WinCC, nur dass wir quasi Formulare+Kompos dazu missgebrauchen), bei dem Alignment ohnehin bestenfalls zu einem unvorhersehbarem Verhalten führen würde, da so viele Einzelteile und Verbindungen zwischen diesen existieren. Praktisch nicht machbar, also auch kein Thema. Vorläufig bin ich auch der einzige, der damit arbeitet. Die Lage der Teile muss auch im Code niemals angefasst werden. Es mag nicht deinem Geschmack entsprechen, aber für Einsatzgebiet empfinde ich das als sehr praktisch. Diese Subjektivität ist für mich jetzt kein Killer-Argument
Warum ist Faulheit schlecht? Bzw. an welcher Stelle empfindest du das als faul? Wäre es dir dann lieber in ~10 Formularen mit je 6-30 solcher Balken alle Beschriftungen von Hand mit Labels zu machen, und diese dann auch noch von Hand auf Werte aus einer DB zu setzen UND noch korrekt zu positionieren da die Zahlenbreite sich ggf. ändert? Da es für alle Balken gleich abläuft, ist das so doch der Inbegriff von Modularität und funktional orientierter Kapselung. Ich kann leider echt nicht folgen.

[Bummi]

@Medium

könntest Du gegf. 2 Bilder(Screenshots) mit unterschiedlichen Extremen bei Deiner Komponente anhängen. Es fällt mir immer noch schwer mir vorzustellen warum Du das so gelöst hast.

[Medium]

Ich hab hier einfach mal ein Screenshot aus einem realen Projekt anonymisiert angehängt. Die Balken sind zwar alle auf 0, aber man sollte erkennen wo sie liegen. hier ist alles recht größzügig, aber es gibt auch Tanks die deutlich kleiner dargestellt werden, in denen noch diverse weitere Anzeigen sind, die teils zwischen die Beschriftungen gesetzt werden müssen damit alles passt. Wenn die Balken dann breiter anklickbar sind, als der eigentliche Balken ist, wirds ein elendes Rumgeschubse wenn man Anzeigen darunter ändern muss. (Glaub mir, ich kenn das ja schon ) Zudem werden dann auch ggf. Repaints ausgelöst, die gar nicht sein müssten. Bei der Menge an Komponenten vereinzelt ein wenn auch leicht merkbarer Gewinn. (Das Bild hier ist wirklich vergleichsweise aufgeräumt noch, die Anlage ist aber auch ein Neubau gewesen. Über die Jahre wird da vieeel geändert und zugefügt. Da tut Reserve gut )
Erstellt sind die Bilder größtenteils aus meiner eigenen Komponentensammlung (Tanks, Leitungszüge, Ventile, etc.) die bereits für unsere DB Struktur geeignet vorbereitet sind, um sie möglichst effizient (und wartungsarm bei Änderung/Erweiterung) laufend mit neuen Daten zu versorgen. Zudem eine Hand voll Edits und Kleinkram. Einsatzort sind Steuerwarten in Industrieanlagen, und unsere Software ist immer eine maßgeschneiderte Individuallösung (jedoch immer auf ähnlicher Basis bzgl. DB, Kommunikation mit den Steuerungen, und Komponenten).
Ist halt eben schon recht speziell, weswegen "End-User-Best-Practices" nicht unbedingt an allen Stellen greifen. Und da die Komponenten ohne das zugehörige garnicht so kleine Subsystem an Serverprogrammen und DB und Infrastruktur praktisch keinen Wert haben, ist es auch ziemlich unwahrscheinlich, dass die mal jemand fremdes in der Hand haben wird.

Die Balken lassen sich übrigens mit Skalen links, recht, beidseitig oder ohne darstellen. Horizontal oder vertikal, und die Zahl in der mitte könnte auch links/rechts/oben/unten vom Balken stehen. Dort wo der Balken nicht ausgefüllt ist, ist die Kompo transparent, so dass ich sie hübsch auf beliebige Untergründe setzen kann. (Hier ausnahmsweise mit nem weissen Shape hinterlegt.)

[Bummi]

Im ersten Moment dachte ich das ganze bis auf die Wincontrol basierten Elemente sein eine Komponente, die sich aus DB-Infos zeichnet, aber nach dem bisherigen Kontext geht es die 3 Füllstandanzeiger?
Die bedenken bezüglich Anordnung und Klickverhalten teile ich weiterhin nicht, das sind IMHO ein paar sinnvoll zu entwerfende Properties, das Verhalten auf Klick/Mousedown lässt sich ja auf einen Fang beschränken.
Aber ich will daraus jetzt auch keine Philosophie machen, wenn es so funktioniert wie es umgesetzt ist.
Danke für den Einblick ....