Align & Miscedits

[starkard]

Hallo zusammen!

Was mich schon länger nervt und mich dazu bringt mal hier nach einer Meinung zu fragen:

Bei nahezu allen Edits unter Misc, z.b. FileNameEd, DirectoryEdit etc., fällt der Glyphbutton aus dem Rand des Owners heraus so das er nicht mehr sichtbar, wenn man Align aktiviert. Das kann nicht gewollt sein oder? Wie könnte man dieses Problem am elegantesten lösen?

Positioniere fast alle Edits mit Align und würde deshlab gerne auf Anchors/Constraints soweit es geht verzichten.

Danke

[Socke]

Hallo zusammen!

Was mich schon länger nervt und mich dazu bringt mal hier nach einer Meinung zu fragen:

Bei nahezu allen Edits unter Misc, z.b. FileNameEd, DirectoryEdit etc., fällt der Glyphbutton aus dem Rand des Owners heraus so das er nicht mehr sichtbar, wenn man Align aktiviert. Das kann nicht gewollt sein oder? Wie könnte man dieses Problem am elegantesten lösen?

Positioniere fast alle Edits mit Align und würde deshlab gerne auf Anchors/Constraints soweit es geht verzichten.

Danke

Align verwendet die Anker (Anchors), ohne die gehts nicht (außer du benutzt ChildSizing des Parents).
Zur korrekten Positionierung müsste man auf den Button zugreifen. Der ist in TCustomEditButton aber protected ergo nicht erreichbar. Borderspacing bring auch nichts, da Abstand zwischen Edit und Button.
Lösung wäre: eigene Komponente basteln. Da kannst du entweder die Komponenten einfach nachbauen oder du erstellst ein Komponente, die einfach ein TCustomEditButton enthält.

Die einfachste Variante für das GUI-Design wäre es wahrscheinlich, jedes Edit-Feld auf ein Panel zu legen (muss aber exakt positioniert und verankert werden) und dann das Panel an die richtige Seite zu schieben.

[Mattias]

Ja, ein Panel waere die sauberste Loesung.

Um existierenden Code nicht zu gefaehrden:
Es muessten dann noch die gaengisten properties und Methoden angepasst werden, so dass das panel sich bedienen laesst wie ein TEdit.

[theo]

Würde man nicht besser gleich in der LCL dem TCustomEditButton ein TCustomControl (oder TGraphicControl?) zugrunde legen?
Dieses Verhalten ist doch nicht korrekt und man sollte dabei imho nicht auf bestehenden Code Rücksicht nehmen.