Delphi-PRAXiS
Seite 5 von 6   « Erste     345 6      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Keine Frames unter Firemonkey (https://www.delphipraxis.net/163363-keine-frames-unter-firemonkey.html)

neo4a 27. Sep 2011 16:42

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von Stevie (Beitrag 1127067)
Ich find es nur spannend zu sehen, wie sich aus einer "fixen Idee" so langsam etwas entwickelt, womit auch andere arbeiten und was nicht nur in der Theorie toll klingt (einen Vorwurf, den man sich als "Designpattern- und Prinzipienfundamentalist" von den "Konservativen" (achtung Ironie :D) oftmals vorwerfen lassen muss)

Zu Recht, zumindest solange der Praxis-Test fehlt. ;)

Wenn Du Dir meine Demo anschaust, dann wirst Du bemerken, dass die Validierung, die an die Bindings angehangen wird, dort irgendwie nicht ganz passt. M.E. gehört da ein Callback zur Validierung in der Datenklasse als Möglichkeit dazu.

Gleichzeitig fehlt mir die Möglichkeit, Property- Änderungen, die die Validierung nicht passieren, zurück weisen zu können.

Ich habe mittels DI/Emballo die Datenklasse im Formular als Interface zur Verfügung gestellt, um die Unit-Referenz zu entsorgen. Leider werden nun die Bindings nicht mehr frei gegeben und ich erhalte ein Memoryleak. Wie werden die TBindings explizit wieder frei gegeben?

Stevie 27. Sep 2011 16:53

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von neo4a (Beitrag 1127081)
Zu Recht, zumindest solange der Praxis-Test fehlt. ;)

Deshalb freu ick mir ja gerade so, dass es etwas in Gang kommt ;)

Zitat:

Zitat von neo4a (Beitrag 1127081)
Wenn Du Dir meine Demo anschaust, dann wirst Du bemerken, dass die Validierung, die an die Bindings angehangen wird, dort irgendwie nicht ganz passt. M.E. gehört da ein Callback zur Validierung in der Datenklasse als Möglichkeit dazu.

Jein, so ist die Validierung auch entkoppelt. Man kann sich aber ohne Probleme eine ValidationRule erstellen, die über ein Callback arbeitet. Problem in dem Demo ist, dass die ValidationRule im Model gebaut wird. Da gehört sich imo nicht hin, sondern im wire up code. Ist aber insgesamt ein Problem, auch in WPF gibt es dahingehend verschiedene Ansätze, das ganze über das ViewModel zu machen oder nicht. Dazu kann man auch an BindingGroups Validations hängen.

Zitat:

Zitat von neo4a (Beitrag 1127081)
Gleichzeitig fehlt mir die Möglichkeit, Property- Änderungen, die die Validierung nicht passieren, zurück weisen zu können.

Hm, wenn die Validierung fehlschlägt, wird eigentlich der Wert nicht übertragen (wenn doch, ist das ein Bug) - was evtl der Fall sein kann, ist, dass das Control nicht "zurückgesetzt" wird. Das enthält dann nämlich noch den invaliden Wert.

Zitat:

Zitat von neo4a (Beitrag 1127081)
Ich habe mittels DI/Emballo die Datenklasse im Formular als Interface zur Verfügung gestellt, um die Unit-Referenz zu entsorgen. Leider werden nun die Bindings nicht mehr frei gegeben und ich erhalte ein Memoryleak. Wie werden die TBindings explizit wieder frei gegeben?

Die Bindings entweder über ihre TBindingGroup freigegeben. Sollten sie keiner BindingGroup angehören über Source oder Target (wenn eins von beiden von TComponent ist).

Falls es noch Probleme gibt, einfach nochmal aktuelle Version uppen und ich schau mal drüber.

Frickler 29. Sep 2011 09:45

AW: Keine Frames unter Firemonkey
 
Nach der reinen Lehre, wie sie z.B. von Vordenkern wie Fowler (*) vertreten wird, muss jede Form durch eine dumme Webseite ersetzbar sein, d.h. irgendeine Art von Eingabelogik hat auf der Form gar nichts zu suchen. Erst beim "Abschicken" wird validiert und der Anwender ggfs. durch farbige Markierungen auf Eingabefehler aufmerksam gemacht.

Meine Meinung: Mit solchen Programmen macht die Arbeit keine Freude...


------------------------------------
(*) schreibt er in "Patterns of Enterprise Application Architecture". Das Buch wurde Jahre vor "AJAX" geschrieben (2002), damals waren Webseiten tatsächlich noch "dumm".

mkinzler 29. Sep 2011 09:49

AW: Keine Frames unter Firemonkey
 
Imho ist es aber besser, bei der Eingabe zu prüfen.
Zudem hat diese Diskussion hier wenig mit dem ursprünglichen Thema zu tun.

Union 29. Sep 2011 09:54

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von Frickler
muss jede Form durch eine dumme Webseite ersetzbar sein, d.h. irgendeine Art von Eingabelogik hat auf der Form gar nichts zu suchen

Ganz meine Meinung. Wie herrlich schnell konnte man früher mit 3270 Terminals arbeiten. Leider sind meine Kunden anderer Ansicht. Am besten soll jedes Feld schon beim Tippen 10 andere aktualisieren.

Zitat:

Zitat von implementation
Ich habe Delphi nach der Turbo verlassen und weiß nicht, wie es mit dem Designer dort aussieht, aber ich bin einfach davon ausgegangen, dass der auch verbessert wurde

Falsch. Der FMX Designer ist eine Katastrophe, ein Rückschritt ohnegleichen. Am besten gleich in der Textformularansicht arbeiten. Dann stört einen auch nicht dass man nach 2 Minuten nicht mehr zwischen Form und Code umschalten kann. Und die Hälft der Hotkeys nicht mehr funktioniert.

neo4a 29. Sep 2011 11:28

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von Stevie (Beitrag 1127082)
Zitat:

Zitat von neo4a (Beitrag 1127081)
Wenn Du Dir meine Demo anschaust, dann wirst Du bemerken, dass die Validierung, die an die Bindings angehangen wird, dort irgendwie nicht ganz passt. M.E. gehört da ein Callback zur Validierung in der Datenklasse als Möglichkeit dazu.

Jein, so ist die Validierung auch entkoppelt. Ist aber insgesamt ein Problem, auch in WPF gibt es dahingehend verschiedene Ansätze, das ganze über das ViewModel zu machen oder nicht.

Im Moment ist sie dafür an das Binding gekoppelt.
Zitat:

Zitat von Stevie (Beitrag 1127082)
Man kann sich aber ohne Probleme eine ValidationRule erstellen, die über ein Callback arbeitet. Problem in dem Demo ist, dass die ValidationRule im Model gebaut wird. Da gehört sich imo nicht hin, sondern im wire up code.

Im Formular ist keine DSharp-Unit erforderlich und das war mein Ziel. Und wenn DSharp zukünftig beide Ansätze unterstützt, kann die Diskussion führen wer will und sich zumindest nicht an mangelnder Funktionalität fest machen ;)
Zitat:

Zitat von Stevie (Beitrag 1127082)
Zitat:

Zitat von neo4a (Beitrag 1127081)
Gleichzeitig fehlt mir die Möglichkeit, Property- Änderungen, die die Validierung nicht passieren, zurück weisen zu können.

Hm, wenn die Validierung fehlschlägt, wird eigentlich der Wert nicht übertragen (wenn doch, ist das ein Bug) - was evtl der Fall sein kann, ist, dass das Control nicht "zurückgesetzt" wird. Das enthält dann nämlich noch den invaliden Wert.

Logisch, und nun?

Zitat:

Zitat von Stevie (Beitrag 1127082)
Zitat:

Zitat von neo4a (Beitrag 1127081)
Ich habe mittels DI/Emballo die Datenklasse im Formular als Interface zur Verfügung gestellt, um die Unit-Referenz zu entsorgen. Leider werden nun die Bindings nicht mehr frei gegeben und ich erhalte ein Memoryleak. Wie werden die TBindings explizit wieder frei gegeben?

Die Bindings entweder über ihre TBindingGroup freigegeben. Sollten sie keiner BindingGroup angehören über Source oder Target (wenn eins von beiden von TComponent ist).

Falls es noch Probleme gibt, einfach nochmal aktuelle Version uppen und ich schau mal drüber.

Ich werde einmal etwas vorbereiten und dazu auch ein Refactoring der Datenklasse durchführen, weil sich mein "Zeig-Du-Mir-Wie's-Geht-AG" ja nun aus der Diskussion verabschiedet hat.

mkinzler 29. Sep 2011 11:34

AW: Keine Frames unter Firemonkey
 
Es gibt zur Zeit doch schon 2 Threads zum Thema Live Bindings

http://www.delphipraxis.net/163299-%...-bindings.html
http://www.delphipraxis.net/163356-%...e-tedit-2.html

Warum postet ihr eure Beiträge, die eher zu diesem Thema passen dort, oder in einem neuen Thread und beschränkt euch hier auf das Thema des Threads ( fehlende Frames unter FMX)?

Stevie 29. Sep 2011 12:38

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von neo4a (Beitrag 1127442)
Zitat:

Zitat von Stevie (Beitrag 1127082)
Zitat:

Zitat von neo4a (Beitrag 1127081)
Gleichzeitig fehlt mir die Möglichkeit, Property- Änderungen, die die Validierung nicht passieren, zurück weisen zu können.

Hm, wenn die Validierung fehlschlägt, wird eigentlich der Wert nicht übertragen (wenn doch, ist das ein Bug) - was evtl der Fall sein kann, ist, dass das Control nicht "zurückgesetzt" wird. Das enthält dann nämlich noch den invaliden Wert.

Logisch, und nun?

ValidationErrors vom Binding auf ein ErrorTemplate (entweder ähnlich zu dem Label in meinem Sample1, oder eine eigene Komponente, z.B. JVCL hat da was, wenn ich mich recht erinnere) binden.

Dass der das Control standardmäßig den invaliden Wert behält, ist by design.

mkinzler 29. Sep 2011 12:50

AW: Keine Frames unter Firemonkey
 
Rede ich chinesisch? :wall:

Stevie 29. Sep 2011 12:53

AW: Keine Frames unter Firemonkey
 
Zitat:

Zitat von mkinzler (Beitrag 1127464)
rede ich chinesisch? :wall:

我不明白


Alle Zeitangaben in WEZ +1. Es ist jetzt 02:44 Uhr.
Seite 5 von 6   « Erste     345 6      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz