Welche Konsequenzen zieht ihr aus den Features für XE2?

[blackfin]

Ah, danke!
Verstehe...da klingt der Name besser als das, was dahinter steckt :-D

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1121212)

Mag mir jemand erklären, wo der Sinn bei Live-Bindings liegen, wenn ich denen mittels Notify erst mitteilen muss, dass sich was geändert hat? Dann hab ich doch fast genau so viel Glue-Code wie vorher auch, oder nicht?

Leider wurde das scheinbar nicht konsequent in die VCL Controls (zu FMX kann ich nicht viel sagen) eingebaut. Einer meiner vielen Kritikpunkte zu den LiveBindings bisher. Theoretisch gibt es über die neue Observer property von TComponent die Möglichkeit, dass, was ich in der extra "Zwischenunit" bei DSharp gemacht habe direkt in den entsprechenden Change methoden der Controls einzubauen. Das scheint auch der Fall zu sein für einige Controls (angeschaut bei TEdit und TCheckBox). Allerdings stimmt dort die Reihenfolge nicht, so dass der Observer feuert, bevor die Property aktualisiert wurde (KeyDown Methode im TCustomEdit z.B.). Außerdem registrieren die TBindingExpression Objekte keine Observer, dies tun nur die TBindLink Objekte (weiterer Kritikpunkt, keine gemeinsame Basisklasse). Diese haben aber noch das Problem, dass das SourceObjekt ein bestimmtes interface (irgendwas mit IEditBindLink oder so) implementieren müssen. Ansonsten bleibt das TEdit einfach ma ReadOnly.

Zitat:

Zitat von Lemmy (Beitrag 1121224)

Was mir am LiveBinding überhaupt nicht gefällt ist die Beschränkung auf TComponent. Gibts dazu irgend welche Aussagen? Die Anbinung des eigenen BusinessModel kann man so vergessen.... Da es ja offensichtlich per RTTI geht, warum wurde das nicht schon viel weiter oben in die VCL eingehängt?

Bindings arbeiten auch mit TObject. Die Property heißt aber anders (DataObject oder so...) Das fällt nur in der IDE nicht auf, weil man dort ja nur TComponent Derivate hat. Ich glaube in der Doku gibts ein Beispiel, wie man einfache Objekte über Bindings aneinander heftet.


Generell kann ich mich des Eindrucks nicht erwehren, dass das Hauptziel der LiveBindings das fitmachen von FMX für DB Geschichten ist. Dann schien jemandem aufgefallen zu sein, dass man da ja noch mehr draus machen kann aber es wurde nicht konsequent und qualitativ hochwertig umgesetzt.

[mquadrat]

Zitat:

Zitat von Stevie (Beitrag 1121256)

Generell kann ich mich des Eindrucks nicht erwehren, dass das Hauptziel der LiveBindings das fitmachen von FMX für DB Geschichten ist. Dann schien jemandem aufgefallen zu sein, dass man da ja noch mehr draus machen kann aber es wurde nicht konsequent und qualitativ hochwertig umgesetzt.

Dafür würde ja auch sprechen, dass es in der Feature-Matrix in der Rubrik Datenbanken steht.

Völlig irritierend finde ich, dass ich entweder zu blöd bin eine konzeptuelle Beschreibung der Live-Bindings zu finden oder das es sowas nicht gibt. Die ganzen Tutorials beziehen sich immer auf die BindingExpression. Und der Unterschied zwischen Managed und Unmanaged Binding wird auch nur sehr sehr sparsam beschrieben. Aber gut, als Programmier-Spielkind probiert man ja eh alles selber aus :-)

[Lemmy]

Zitat:

Zitat von Stevie (Beitrag 1121256)

Bindings arbeiten auch mit TObject. Die Property heißt aber anders (DataObject oder so...) Das fällt nur in der IDE nicht auf, weil man dort ja nur TComponent Derivate hat. Ich glaube in der Doku gibts ein Beispiel, wie man einfache Objekte über Bindings aneinander heftet.

Danke für den Hinweis. muss ich gleich nochmal schauen...

Zitat:

Zitat von Stevie (Beitrag 1121256)

Generell kann ich mich des Eindrucks nicht erwehren, dass das Hauptziel der LiveBindings das fitmachen von FMX für DB Geschichten ist. Dann schien jemandem aufgefallen zu sein, dass man da ja noch mehr draus machen kann aber es wurde nicht konsequent und qualitativ hochwertig umgesetzt.

Dann bleibt zumindest die Hoffnung, dass sich da in den nächsten Jahren noch was tut - Luft nach oben ist jedefalls ;-)

[jaenicke]

Zitat:

Zitat von Lemmy (Beitrag 1121224)

selbst beim Observer-Pattern musst Du ja mitteilen, dass sich was verändert hat. Was mir am LiveBinding überhaupt nicht gefällt ist die Beschränkung auf TComponent. Gibts dazu irgend welche Aussagen?

Das ist nicht darauf beschränkt, siehe Hilfe:
http://docwiki.embarcadero.com/RADSt...ry:LiveBinding
Speziell:
http://docwiki.embarcadero.com/RADSt...reated_Objects

[Stevie]

Zitat:

Zitat von Lemmy (Beitrag 1121259)

Dann bleibt zumindest die Hoffnung, dass sich da in den nächsten Jahren noch was tut - Luft nach oben ist jedefalls ;-)

Ich werd DSharp auf jeden Fall weiterentwickeln (geplant für die DataBindings direkt sind unter anderem die Verbesserung der Designeditors und eine DWS Integration) 8-) Und bis wir Compiler Support für Bindings sehen, wird mindestens ein weiteres Jahr vergehen (ich versteh es nach wie vor nicht, wie man so eine Chance vertun kann...) Zumindest (leider) sind sie mir damit technisch nicht vorraus (Nutzung von RTTI und strings und Runtime Evaluation)

P.S. Und das Grid müsste ich mal in Angriff nehmen, um dort Listen mit Datenobjekten o.Ä. anhängen zu können.

[mquadrat]

Aber um auch mal was Positives zu schreiben: Das Mitliefern von Document Insight ist super :thumb:

[jaenicke]

Zitat:

Zitat von bernerbaer (Beitrag 1119955)

Zitat:

Delphi 64-bit compiler is worse than 32-bit one. It produces inefficient and much slower code (64-bit code optimizer is scheduled for XE3, as I see over QC). [...]

[...] wenn nun obige Aussage einen wahren Kern enthält, wäre das für mich fatal. Weshalb sollte ich dann nicht wie bis anhin FPC benutzen um 64 bit Code zu compilieren wenn ich solchen benötige?

Hier findest du jetzt etwas dazu:
http://delphitools.info/2011/09/02/f...t-performance/

[Jacques Murell]

Ich wollte jetzt nicht extra einen neuen Thread aufmachen: Bisher nur BDS2006 im Einsatz gehabt, soeben XE2 Trial installiert. Leeres Win32-Projekt mit zwei Edits und einem Button "wiegt" 7MB. Hab ich irgendwas verpasst? :gruebel:

[mkinzler]

-erweiterte RTTI
-Debugmodus?

[Jacques Murell]

Scheinbar war es ein Fehler ein paar Versionen auszulassen, das ganze Projektmanagement ist irgendwie anders. :stupid: Wie kann ich denn das Projekt ganz normal erzeugen lassen? Bisher lag das Compilat im Projektordner, da ist jetzt nichts außer ein Ordner Win32, darin ein Ordner debug und da liegt die 7MB EXE.

[mkinzler]

Standradmässig wird ein Projekt als Dubprojekt angelegt. Man kann in der Projektverwaltung aber auf Release umstellen

[Phoenix]

Da gehört sie ja auch hin ;-)
In den Projektoptionen sollte es aber möglich sein den Ausgabepfad an irgendeine falsche Stelle hinzubiegen.

[Jacques Murell]

Ok, ich habe in den Projektoptionen jetzt auf RELEASE gestellt. Daraufhin sollte ich eine *.optset anlegen. Gesagt getan, gespeichert. Trotzdem wird im Projektordner keine Exe erstellt. Entweder bin ich zu blöd oder blind.

[mkinzler]

Nach dem Umstellen musst du das Projekt neu erzeugen

[Jacques Murell]

Hatte ich bereits, neu kompiliert und neu erzeugt. Außer der 7MB Debug-Exe weiterhin kein "Release" zu finden im Projekordner.

[himitsu]

Zusätzliche Debuginfos landen doch nicht in der EXE?
Und die RTTI kann man irgendwie teilweise abschalten.

[Jacques Murell]

Ah ich habs gefunden. Neben den Einstellungen in den Projektoptionen muss man in der Projektverwaltung (rechts) auch nochmal extra Release auswählen. Das muss man ja erstmal wissen. ;)

[USchuster]

Zitat:

Zitat von himitsu (Beitrag 1121505)

Zusätzliche Debuginfos landen doch nicht in der EXE?

Natürlich landen TD32 Debuginformationen (Parameter -V und -VN) in der Exe. Um diese zu deaktivieren ist in der Konfiguration "Debug-Informationen" auf der Seite Delphi-Compiler\Linken zu deaktivieren. "Mit externen Debug-Symbolen" wird für das (Remote)debuggen beim OS X oder Win64 Target benötigt, die Option erzeugt die externe .RSM Datei und kann für Win32 deaktiviert werden.

[jaenicke]

Zitat:

Zitat von Jacques Murell (Beitrag 1121509)

Ah ich habs gefunden. Neben den Einstellungen in den Projektoptionen muss man in der Projektverwaltung (rechts) auch nochmal extra Release auswählen. Das muss man ja erstmal wissen. ;)

Richtig, in den Einstellungen legst du die Einstellungen für die einzelnen Konfigurationen fest, stellst sie aber nicht ein.

Umgeschaltet auf Release ist die Exe 1,5 MiB groß.

Schön (aber nicht unbedingt sofort überschaubar) ist an der Stelle z.B. auch, dass du dir mehrere Konfigurationen anlegen kannst, die sich z.B. nur im Ausgabeverzeichnis und einer Compilerdefinition unterscheiden. In der übergeordneten Einstellung kannst du aber dennoch Einstellungen für alle Unterkonfigurationen setzen.

[mschaefer]

Meine eigenen Projekte werden sicher nicht zeitnah nach FRM portiert werden, dafür sind die verweneten Komponenten zuweit von den VCL-Varianten entfernt.

Mal von FRM-abgesehen scheint mir erwähnenswert:

+ Mit FastReport ist eine gute Reportinglösung gefunden worden
+ FastScript gibt eine solide Grundlage.
+ Indies werden kontinuierlich weitergepflegt.
+ das Aufräumen der VCL-Palette war eine gute Idee.

- Ernüchternd ist Atozed´s Intraweb Weiterentwicklung.

Grüße in die Runde

[Robotiker]

Zitat:

Zitat von mschaefer (Beitrag 1123256)

Meine eigenen Projekte werden sicher nicht zeitnah nach FRM portiert werden, dafür sind die verweneten Komponenten zuweit von den VCL-Varianten entfernt.

Ja, das ist für die meisten Delphi Entwickler eine neue Situation.

Aber die Lage ist heute viel günstiger, als damals beim C++ Builder X, wo man den Leuten einfach vor den Kopf gesagt hat: "VCL gibts nicht mehr". Da haben viele erstmal gemerkt, wie abhängig ihre Geschäftslogik von der VCL ist. Die musten dann auf die harte Tour lernen, wie man Logik und GUI trennt.

Wir hatten damals den Vorteil, dass wir in verschiedenen Projekten mit dem BCB oder VC++ gearbeitet haben. Die ganzen Kernkomponenten waren so ausgelegt, dass sie mit beiden Umgebungen arbeiteten.
So konnten wir recht schnell mit unserem Hauptprodukt von einer VCL-Anwendung zu einer Architektur mit VC++ Kern und C# Frontend wechseln.

Den Frontend können wir heute optional durch Qt ersetzten, Firemonkey wäre kurzfristig möglich.

Viele Delphi-Projekte dürften dagegen von Kopf bis Fuss von der VCL abhängen. Nicht zuletzt weil das
für die meisten Komponenten von Drittanbietern auch gilt. Da hat man es mit dem C++ Builder sicher leichter, weil die meisten externen C++ Libs keine VCL-Abhängigkeiten haben.

Grüße

Robotiker