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

[stahli]

[OT]Jetzt macht auch Dein NickName Sinn. ;-)[/OT]

[Florian Hämmerle]

Zitat:

Zitat von stahli (Beitrag 1117844)

[OT]Jetzt macht auch Dein NickName Sinn. ;-)[/OT]

[OT]Ich hab schon anderes vermutet. Jetzt bin ich ja grad beruhigt ;)[/OT]

[QuickAndDirty]

Zitat:

Zitat von stahli (Beitrag 1117844)

[OT]Jetzt macht auch Dein NickName Sinn. ;-)[/OT]

^^
Ich dachte das wäre von vorneherrein klar! Mein highlight...object-adressen-strings+Objekte eben in einer THashedStringlist speichern...

HashedStringlist.addObject(inttostr(integer(meinOb jekt)),meinObjekt);
Mit sowas sollte eine Garbage Collection umgehen können!!! *verrückt kicher*

[bernerbaer]

Zurück zur Ausgangsfrage:
_ich_ habe etwas Angst vor der "Überladenheit" von XE2. Mir persönlich hätte ein 64Bit Compiler gereicht, dafür das ausgereift und dazu alte seit Jahren mitgeschleifte Bugs endlich beheben. Besteht jetzt nicht die Gefahr, dass zwar alles integriert ist, aber auch hunderte von neuen Bugs auftauchen werden? Was ich von Firemonkey zu halten habe, werde ich erst wissen, wenn ich es mal gesehen habe, doch als reiner Windowsentwickler, der sich (leider) nur mit dem Windows API auskennt, denke ich, dass ich mich kaum mehr vertieft in neue Betriebssysteme einarbeiten werde bzw kann. So schnell schnell ein bestehendes oder neues Projekt für ein anderes OS zu kompilieren, vermute ich, wird so oder so nicht funktionieren und ich befürchte, dass sich da viele falsche Hoffnungen machen und dann frustriert das Handtuch werfen werden bezüglich Firemonkey. Ein Code mehrere OS das funktioniert m.E nur für die wenigsten Projekte. Nun ich lasse mich gerne überraschen von XE2 und wenn es denn erhältlich ist, werde ich mich natürlich auch mit Firemonkey mal auseinandersetzen.

[EarlyBird]

Ein Statement von devexpress.
Interessant für für Devexpress VCL USER

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1117834)

Es wäre m.E. schön, wenn der Compiler dies automatisch für alle Objekte regeln würde (zumindest für Objekte der eigenen Application) und neben Property-Pointern auch für Variablen.

Gibt es doch schon?
Interfaces

Außer wenn jemand deren Zeiger schmutzig herumcastet, aber dafür gibt es ja die Möglichkeit die Referenzzählung manuell anzupassen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1117934)

Zitat:

Zitat von stahli (Beitrag 1117834)

Es wäre m.E. schön, wenn der Compiler dies automatisch für alle Objekte regeln würde (zumindest für Objekte der eigenen Application) und neben Property-Pointern auch für Variablen.

Gibt es doch schon?
Interfaces

Interfaces wie sie Delphi implementiert haben Schwachstellen die bei einem System mit GC nicht auftreten. Du wirst auch schon in die Falle getreten sein in dem du noch ein Nicht-Interface-Referenz gehalten hast und die automatische Refernzzählung die die instanz hinterm rücken zerstört hat. Oder mal versucht GUI-Controls per Interfaces zu Verwaltung wo dann die Parent-Freigabe zur freigabe des Childs geführt hat - trotz noch gültigem Interface-Zeiger.

[mquadrat]

Das FireMonkey Statement von DevExpress ist interessant. Entweder alle Komponentenhersteller halten sich wie DevExpress zurück, oder wir erleben das Rennen um das erste FireMonkey Grid :-) Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

[Bernhard Geyer]

Zitat:

Zitat von mquadrat (Beitrag 1117975)

Das FireMonkey Statement von DevExpress ist interessant. Entweder alle Komponentenhersteller halten sich wie DevExpress zurück, oder wir erleben das Rennen um das erste FireMonkey Grid :-) Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

Das sie sich zurückhalten sehe ich nicht als Problem. Vermutlich werden sie ähnlch wie andere Hersteller (LMD) schön fleißig für VCL.NET und CLX Portierung vorgenommen haben um dann wenn sie fertig waren festzustellen das diese Libraries wieder eingestellt wurden - Was hätte man mit dieser vergeudeten Entwicklerzeit alles machen können. Deshalb will man erstmal sehen wie das wirklich aufgenommen wird.

[mquadrat]

Jep, so hat es DevExpress ja auch geschrieben. Das Problem ist nur das ohne sinnvolles Grid FireMonkey zum Scheitern verurteilt ist. Es muss ja nicht dermaßen überfrachtet sein, wie manche der Third-Party-Grids, aber mehr als das VCL StringGrid braucht es schon.

Wenn also alle so wie DevExpress reagieren haben wir die Situation, dass keiner FireMonkey einsetzt, weil ein Grid fehlt und es kein Grid gibt weil keiner FireMonkey benutzt ;)

Aber warten wir erstmal ab, bis wir die ersten FireMonkey Programme am laufen haben

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1117978)

Jep, so hat es DevExpress ja auch geschrieben. Das Problem ist nur das ohne sinnvolles Grid FireMonkey zum Scheitern verurteilt ist. Es muss ja nicht dermaßen überfrachtet sein, wie manche der Third-Party-Grids, aber mehr als das VCL StringGrid braucht es schon.

Wenn also alle so wie DevExpress reagieren haben wir die Situation, dass keiner FireMonkey einsetzt, weil ein Grid fehlt und es kein Grid gibt weil keiner FireMonkey benutzt ;)

Aber warten wir erstmal ab, bis wir die ersten FireMonkey Programme am laufen haben

Wenn man mit nem Listview oder einer Listbox sowas machen kann wie in WPF braucht kein Mensch ein Grid.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1118016)

Wenn man mit nem Listview oder einer Listbox sowas machen kann wie in WPF braucht kein Mensch ein Grid.

Denke ich auch. Ob die Komponenten nun Grid oder ListView oder "WundercontroldasAllesKann" heißt ist eigentlich egal. Solange es was gibt mit dem man Daten tabelarisch/als List Anzeigen kann und genügend Schalter für die eigene Bedürfnisse gibt ist es gut. Und wenns noch List + Baum kann (wie Kompos von LMD/TMS oder VST) dann braucht man auch kein eigene Treeview-Komponente.

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1117975)

Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

Ich weiß nicht welches Statement du genau meinst, aber die Kommentare zu den Grids beziehen sich nur auf Grids von DevExpress. Deshalb interpretiere da nichts hinein, was da gar nicht steht. ;-)

[cookie22]

Ich halte es für mehr als weit hergeholt, dass der Erfolg von Fire Monkey von einer Komponente abhängen sollte.

[Florian Hämmerle]

Zitat:

Zitat von cookie22 (Beitrag 1118058)

Ich halte es für mehr als weit hergeholt, dass der Erfolg von Fire Monkey von einer Komponente abhängen sollte.

Wenn die Component Library von FireMonkey allerdings gegenüber der normalen VCL Vorteile bietet, ist die Chance größer, das FM gut aufgenommen wird.

[cookie22]

Das aber an einem Grid fest zu machen, ist für mich nicht nachvollziehbar.

Ausserdem wird schon jemand eines schreiben ob nun Commercial oder Freeware, geben tut es das ganz sicher. Um sowas würde ich mir gar keinen Kopf machen. Hauptsache das ganze läuft von Anfang an stabil, sowas seh ich als viel wichtiger an.

[Florian Hämmerle]

Das ist ganz klar. Ich sehe Firemonkey auch als Chance, Altlasten los zu werden. Wenn man nur mal bedenkt, wie alt manche Komponenten schon sind und was man damals noch gar nicht bedacht hat, heute aber verlangt wird. Da können einige schöne Projekte draus werden :)

[DSCHUCH]

Hoi,

Kann mir eigentlich mal jemand verraten was der unterschied zwischen dem neuen "databindings-feature" und dem bestehenden DataSet-DataSource-Funktionen ist?

[Phoenix]

Mit dem Datasource-quatsch ist es z.B. nicht möglich, ein Objekt mit belieben Properties (z.B. Text, Enabled, Action) and einen Button zu binden, wobei sich die Caption vom Button ändern wenn ich den Text des Objektes ändert und der Button-state sich ändert wenn ich Enabled auf dem Objekt umstelle.

[Stevie]

Zitat:

Zitat von DSCHUCH (Beitrag 1118079)

Hoi,

Kann mir eigentlich mal jemand verraten was der unterschied zwischen dem neuen "databindings-feature" und dem bestehenden DataSet-DataSource-Funktionen ist?

Bestehende DataSet-DataSource-Funktion basiert darauf, dass deine Daten in einem TDataSet (oder davon abgeleitet) vorliegen und die nötigen Dinge in den Controls implementiert sind (auf TDataSource Events reagieren, etc). In der Theorie kannst du bei den LiveBindings ein TColorBox.Selected and dein Form1.Color binden und damit die Farbe wechseln. Oder du kannst aus einem TCustomer Object die Property LastName und FirstName an 2 Edits binden. Oder die property PaymentMethod an eine TComboBox, in der du die möglichen Werte auswählen kannst. Mehr zu DataBinding und Delphi siehe meine Sig ;)

[DSCHUCH]

hm. ok, also ein automatisierter event-handler auf ein property-change inkl. automatismen wie getvalue für oberflächenfelder.... interessant auf jeden fall.

also zumindest wenn ich das nach 30 sek überfliegen deiner signatur richtig verstehe. ^^

wird damit eigentlich auch das problem gelöst das man bei events eine 1:1 beziehung hat? also kann man damit (automatisch, selbst bauen kann ich es mir natürlich) mehrere ereignis-proceduren an ein ereignis hängen?

ein property wäre ja zB datasetchange oder recordchange (oder einfach nur recno) von dataset.

oder ist das ausschliesslich für diese "value" / oberflächenanzeigen gedacht?

[Stevie]

Zitat:

Zitat von DSCHUCH (Beitrag 1118089)

hm. ok, also ein automatisierter event-handler auf ein property-change inkl. automatismen wie getvalue für oberflächenfelder.... interessant auf jeden fall.

also zumindest wenn ich das nach 30 sek überfliegen deiner signatur richtig verstehe. ^^

wird damit eigentlich auch das problem gelöst das man bei events eine 1:1 beziehung hat? also kann man damit (automatisch, selbst bauen kann ich es mir natürlich) mehrere ereignis-proceduren an ein ereignis hängen?

ein property wäre ja zB datasetchange oder recordchange (oder einfach nur recno) von dataset.

oder ist das ausschliesslich für diese "value" / oberflächenanzeigen gedacht?

Nicht falsch verstehen, was ich auf meinem Blog schreibe bezieht sich auf meine Implementierung (die ab Delphi 2010 läuft) und hat nicht direkt etwas mit den LiveBindings in Delphi XE2 zu tun. Wie diese implementiert sind, wird sich zeigen. Und wo die Features und Möglichkeiten sich überschneiden oder auch nicht.

In meiner Library gibt es Multicast Events (ein Ereignis ruft mehrere Eventhandler auf). Observer Pattern halt. Und wie sehr nun Events für Property changes in alle möglichen Klassen der RTL und VCL eingebaut werden, ist auch abzuwarten, aber ich glaube eher weniger.

[mquadrat]

Zitat:

Zitat von cookie22 (Beitrag 1118058)

Ich halte es für mehr als weit hergeholt, dass der Erfolg von Fire Monkey von einer Komponente abhängen sollte.

Sicher ist das etwas übertrieben, aber Grids dürften wohl die meist zugekaufte Komponente bei Delphi sein, oder irre ich da? Unsere Wawi hat auf fast jedem Form ein Grid hängen. Und ich möchte das Ding definitiv nicht selber bauen. Natürlich ist es zu früh das im Detail zu diskutieren, aber die ersten Demos beschäftigen sich nun mal vor allem mit fliegenden Bildchen. Das ist wie als WPF rauskam, da haben wir in der MS Veranstaltung Videos auf 3D Würfel gepackt und die rotieren lassen. Alles nett, aber für ne Geschäftsanwendung nicht zu gebrauchen. Die hätten damals eher mal einen fähigen GUI-Editor machen sollen, der kam ja erst wesentlich später.

[cookie22]

Ich wette Fire Monkey gibt der Komponentenentwicklung unter Delphi wieder einen Schub und wir sehen auch viele neue Commercial und Freeware Kompos. Da gibt es sicher auch das ein oder andere gute Grid.

[MEissing]

Zitat:

Zitat von cookie22 (Beitrag 1118428)

Ich wette Fire Monkey gibt der Komponentenentwicklung unter Delphi wieder einen Schub und wir sehen auch viele neue Commercial und Freeware Kompos. Da gibt es sicher auch das ein oder andere gute Grid.

Ich wüsste nichts, was an dem FireMonkey Grid "schlecht" ist....

[mquadrat]

@Matthias

Wir auch nicht ;)

[neo4a]

Wer will, kann sich hier noch ein Bild machen (Grid ist ganz unten) oder sich das Kompilat aus dem Anhang anschauen.

[himitsu]

Ich hatte es so verstanden, daß es kein Grid gibt und sich deshalb alle beschweren?

Nja, wenn es Keines gibt, dann kann es auch nicht schlecht sein. :stupid:

[mquadrat]

Zitat:

Zitat von himitsu (Beitrag 1118527)

Ich hatte es so verstanden, daß es kein Grid gibt und sich deshalb alle beschweren?

Nja, wenn es Keines gibt, dann kann es auch nicht schlecht sein. :stupid:

Meine Befürchtung war, dass es sowas wie das Std-StringGrid in der VCL ist, mit dem man nicht so wahnsinnig viel anfangen kann. Von den alle zwei Wochen wiederkehrenden Fragen ala "Wie mache ich da ne Zeile farbig" mal ganz abgesehen.

Aber das Grid im verlinkten Beitrag schaut ja soweit brauchbar aus.

[himitsu]

Zitat:

Zitat von mquadrat (Beitrag 1118528)

Von den alle zwei Wochen wiederkehrenden Fragen ala "Wie mache ich da ne Zeile farbig" mal ganz abgesehen.

Da hab "selbst ich" inzwichen rausbekommen ... nur das "wie mache ich die selektierte Zeile farbig" bekomm ich nicht hin :cry:

[mkinzler]

Geht genauso must halt nur auf Selektion überprüfen

[cookie22]

Zitat:

Zitat von MEissing (Beitrag 1118430)

Zitat:

Zitat von cookie22 (Beitrag 1118428)

Ich wette Fire Monkey gibt der Komponentenentwicklung unter Delphi wieder einen Schub und wir sehen auch viele neue Commercial und Freeware Kompos. Da gibt es sicher auch das ein oder andere gute Grid.

Ich wüsste nichts, was an dem FireMonkey Grid "schlecht" ist....

Hat ja auch niemand behauptet, irgendwer hat gesagt es ist gar keins dabei.

[mkinzler]

So entstehen Gerüchte ...

[mquadrat]

Ich schrieb "kein sinnvolles" - von gar keinem hab ich nicht geredet ;) Ich bezog mich nur auf die Aussage im DevExpress Blog und die war ja nicht "gutes Grid is dabei, daher entwickeln wir keins", sondern "Erst mal abwarten ob das überhaupt jemand nutzt". Sorry für die Verwirrung ;)

[Chemiker]

Hallo,

gibt es eigentlich Informationen, ob der integrierte Assembler von Delphi auch auf 64Bit angepasst wird.

Bis bald Chemiker

[jaenicke]

Ich zitiere mal was bereits vor einiger Zeit dazu veröffentlicht wurde:

Zitat:

Zitat von David Intersimone (auf Englisch)

• Du kannst keine Assemblerblöcke in Pascalfunktionen nutzen. Nur komplett in Assembler geschriebene Funktionen.
• Der Stack muss bei jedem Unterprogrammaufruf mit CALL an 16-Byte ausgerichtet sein.
• Die ersten vier Parameter werden jetzt in RCX, RDX, R8 und R9 übergeben, bzw. bei MMX in XMM0 bis XMM3.

Mehr siehe hier:
http://www.embarcadero.com/products/delphi/64-bit

[bernerbaer]

Ich habe auf der Seite von David Intersimione folgenden Kommentar gefunden:

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). It doesn’t support Extended type, only 64-bit emulation (QC #92342). So only purpose of 64-bit compiler is to add a several lines to new feature list, though it is useless?

Live Bindings feature has been met sceptically too (QC #97444).

Leider habe ich unter den angegebenen QC Nummern bei Embarcadero nichts gefunden(Either there is no report #xxxxx, or you are not authorized to see that report). Gibt es dazu evtl.noch weitere Infos?

für _mich_ ist die 64Bit Unterstützung der Hauptgrund für einen allfälligen Kauf von XE2 (Firemonkey wäre für mich höchstens ein gern genommenes Gadget, das ich evtl. mal auch einsetzen werde), 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?

[jaenicke]

Wenn ich mir den Assemblercode so anschaue (nicht bei XE 2, sondern früher), habe ich allgemein den Eindruck, dass etwas schlechter optimiert wird. Allerdings nicht so schlecht, dass der Code wirklich langsam würde, aber eben ein paar unnötige Instruktionen immer wieder mal, die man manuell nicht machen würde. Einfach ist das aber auch nicht das automatisiert zu optimieren.

Die Optimierung ist beim FPC allerdings noch schlechter. Zumindest bei einfachen Tests.

Aber wo wir bei Optimierung sind, da widerspricht sich derjenige selbst.

Zitat:

Zitat von bernerbaer (Beitrag 1119955)

Zitat:

It doesn’t support Extended type, only 64-bit emulation (QC #92342).

Einerseits möchte er gern optimierten Code, andererseits einen der langsamsten Datentypen überhaupt (da bisher aufwendig softwareseitig emuliert) weiter haben...

[Insider2004]

Es ist richtig, den Extended endlich aus Delphi XE2 rauszuwerfen, weil er nicht IEEE genormt ist. Ausserdem ist er nicht portabel.

[Uwe Raabe]

Zitat:

Zitat von Insider2004 (Beitrag 1119961)

Es ist richtig, den Extended endlich aus Delphi XE2 rauszuwerfen, weil er nicht IEEE genormt ist. Ausserdem ist er nicht portabel.

Was allerdings zu der leicht paradoxen Situation führt, daß in 32-Bit mit höherer Präzision gerechnet werden kann, als mit 64-Bit.