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

[mkinzler]

Es lebe Lazarus der neue Messias :mrgreen:

Genauso falsch wie eine ubekannte neue Technologie zu in den Himmel zu loben, ist es diese im Vorraus zu verdammen.

[MEissing]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

Ich würde jetzt nicht soviel auf Firemonkey geben! Manche hören sich an, als würde jetzt der Messias kommen. Firemonkey ist noch reine Frickel-Software. Das ist jetzt innerhalb eines halben Jahres zusammengebastelt worden und stammt von einem russischen Projekt. Ich würde jetzt keine Wunder erwarten. Wir können froh sein, wenn einem das Programm nicht alle 10 Sekunden um die Ohren fliegt. Das Ding ist bestimmt 10 Jahre von der VCL-Stabilität entfernt. Von den Funktionen her bestimmt auch. Emba hat leider wiedermal den Fehler gemacht, 2 Frameworks aufzusetzen (anders ging es wahrscheinlich auch gar nicht). Lazarus LCL ist da weit voraus. Das ist von Design her schon Cross implementiert.

Ja... Neee.... iss klar!

(Sorry für Fullquote)

[geskill]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

... und stammt von einem russischen Projekt. ...

Nur weil es "russisch" ist muss es noch lange nicht schlecht sein. Mit solchen Aussagen sollte man in der "Öffentlichkeit" immer vorsichtig umgehen.

Aber eines ist sicher uns stehen spannende Wochen bevor :-D

[WladiD]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

...Das ist jetzt innerhalb eines halben Jahres zusammengebastelt worden und stammt von einem russischen Projekt...

VGScene und DXScene gingen im Juli 2009 online und waren vom Feature-Set schon sehr weit fortgeschritten. Also hat es mind. 2 Jahre Reifezeit hinter sich und man kann ein durchaus stabiles Produkt erwarten. Oder meinst du Emba. kauft mal irgendetwas, nur weil es schön aussieht?

Übrigens kommen sehr viele fähige Programmierer aus Russland ... wie auch aus anderen Ländern ... die Herkunft sagt rein gar nichts über die Fähigkeiten aus ... nur die Mentalität/Kultur ist eine andere ...

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

... Das ist jetzt innerhalb eines halben Jahres zusammengebastelt worden und stammt von einem russischen Projekt. Ich würde jetzt keine Wunder erwarten. ... Das Ding ist bestimmt 10 Jahre von der VCL-Stabilität entfernt.

Hoffen wir doch das einige stabilitätsproblem der VCL nicht vorhanden sind.
Und wir haben selbst GUI-Kernkomponenten von osteuropäischen entwicklern im Einsatz und haben keine größeren Probleme.

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

Von den Funktionen her bestimmt auch. Emba hat leider wiedermal den Fehler gemacht, 2 Frameworks aufzusetzen (anders ging es wahrscheinlich auch gar nicht). Lazarus LCL ist da weit voraus. Das ist von Design her schon Cross implementiert.

Die VCL wird niemals meher Crossplattform fähig werden. Jeder Grundlegende Anpassung/Änderung würde hier mit Sicherheit viele GUI-Komponentenbibliotheken vor große Probleme stellen. Vor dem Mio. Quellcodezeilen von Entwicklern ganz zu schweigen die selbst über die Unicode-Implementierung fluchen obwohl diese bei halbwegs vernünftiger eigener Implementierung größtenteils Problemlos abläuft.


Und dann lieber eine zweite Bibliothek bevor wir CLX 3.0 (nach CLX und CLX 2.0 ALA VCL.NET) erleben.

[Stevie]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

stammt von einem russischen Projekt

Ohne die Russen und Chinesen würd's doch Delphi garnimma geben! /sarcasm off :lol:

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

Lazarus LCL ist da weit voraus. Das ist von Design her schon Cross implementiert.

An FireMonkey (ohne konkrete Kritikpunkte außer allgemeinen Verdächtigungen wohlgemerkt) zu zweifeln solange du es nicht selbst testen konntest ist eine Sache, aber ausgerechnet Lazarus als besseres Beispiel zu nennen ist der Witz des Jahrhunderts... :roll:

[cookie22]

KSDev war schon extrem weit, bevor Emba das gekauft hat. Ich wüßte nicht was daran schlecht sein soll. :roll:

[jaenicke]

Naja, gewisse Aussagen kommen halt immer aus denselben Ecken. :roll:

[DeddyH]

Zitat:

Zitat von jaenicke (Beitrag 1117329)

Naja, gewisse Aussagen kommen halt immer aus denselben Ecken. :roll:

Wie wahr, gell? :mrgreen:

[JamesTKirk]

Zitat:

Zitat von Insider2004 (Beitrag 1117284)

Ich würde jetzt nicht soviel auf Firemonkey geben! Manche hören sich an, als würde jetzt der Messias kommen. Firemonkey ist noch reine Frickel-Software. Das ist jetzt innerhalb eines halben Jahres zusammengebastelt worden und stammt von einem russischen Projekt. Ich würde jetzt keine Wunder erwarten. Wir können froh sein, wenn einem das Programm nicht alle 10 Sekunden um die Ohren fliegt. Das Ding ist bestimmt 10 Jahre von der VCL-Stabilität entfernt. Von den Funktionen her bestimmt auch. Emba hat leider wiedermal den Fehler gemacht, 2 Frameworks aufzusetzen (anders ging es wahrscheinlich auch gar nicht). Lazarus LCL ist da weit voraus. Das ist von Design her schon Cross implementiert.

Darf ich dich daran erinnern, dass KSDev dieses Framework ursprünglich auch für Lazarus/FPC implementiert hatte. Was auch letztendlich ein Grund sein dürfte, dass Embarcadero aktuell für iOS Kompilierung FPC einsetzt.

Gruß,
Sven

[QuickAndDirty]

Ich weiß nicht ...
mit Morfik kann ich alle Plattformen und HandyPlattformen und das Internet beliefern...mit einem einzigen Code...

Habe das schon Spaß drann.

Und ansonsten hat mich das billige C# VS 2010 Express das ich gerade für ein privates Projekt benutze sowas von weggehauen...klasse teil. Überlege schon mir ein W7P Handy zu kaufen...

Firemonkey ist sicher cool. Aber wir haben gerade ein 1,2 Mio Code Zeilen Projekt von BDE auf Anydac umgestellt, das war harte Arbeit, weil wir es erst mit DBISAM , dann mit ElevateDB versucht haben...und beides war scheiße..... Dieser Umstellungsprozess hat Jahre an Zeit in Anspruch genommen....und wird sicher noch mehr in Anspruch nehmen, wenn der erste Pilotkunde sich damit beschäftigt (also ab Freitag, oh dear).
Das ganze ist deswegen so schwierig weil ein Großteil der da Programmiert wurde in Delphi1 und Delphi2 Programmiert wurde....Wo rad eben hieß alles Datenkomponenten auf die Formulare zu legen und alles über die dämlichen DB-Controls zu machen....außerdem konnte man Formulare noch nicht vererben was bei dieser Anwendung ungefähr 100000 Zeilen im ganzen Programm verteilten Kode gespart hätte.
Also das war jetzt DIE harte Umstellung. Mehrere Jahre arbeit und noch kein Bisschen für Kunden "sichtbaren" Mehrwert für das Programm geschaffen...

Da wir in gerade ein Neues Oberflächen Framework und Bedienkonzept für unsere Anwendungen entwickeln auf Basis von VCL wäre es ziemlich übel wenn die VCL stirbt. Aber wenigstens hat Embarcadero selbst mit Firemonkey einen Neuen Standard gesetzt dem man sich dann zuwenden kann. Auch wenn ich das töten VCL zeimlich blöde fände...nun zumindest liegt sie im Quellcode vor...anders als die BDE...da hat Borland sich wohl zu sehr geschämt den offen zulegen als sie begraben wurde.


Ein großes Problem dürfte noch die 64 Bit Geschichte und die Unicode Geschichte werden...aber das ist eine Umstellung die man ja sowieso machen muss und zum Glück nun auch machen kann(dat 64Bit dingen).

Was ich einfach mal sagen will ist, das es problematisch ist, wenn man als Entwickler dazu gedrängt wird ständig Kode der mal funktionierten umzustellen...Wo man eigentlich lieber Features für Kunden ausrollen möchte!

[mkinzler]

Zitat:

Ich weiß nicht ...
mit Morfik kann ich alle Plattformen und HandyPlattformen und das Internet beliefern...mit einem einzigen Code...

Die Portierung nach Morfik dürfte sich aber um einiges komplexer gestalten als der Umsteig von einer VCL zu einer FMX-Oberfläche. (Wenn bei Morfik natürlich auch Pascalsyntax möglich ist)

Grundsätzlich finde ich es komisch, dass seit Jahren gemeckert wird, dass sich bei Delphi nichts tut und jetzt wird gemeckert, dass dafür Änderungen im Code notwendig sind, was ja nicht unbedingt der Fall ist. Nur wenn man für mehrere Plattformen entwicklen will; die VCL ist nunmal zu sehr mit der WinAPI verzahnt, dass eine Portierung sinnvoll/möglich wäre.

[Florian Hämmerle]

Und wer gibt die Garantie, dass Morfik nicht in den kommenden Jahren / Monaten eingestellt wird oder die Syntax komplett umgestellt wird?

Seit doch alle froh, dass jetzt die Features kommen, nach denen schon seit Jahren gebettelt wird. Wenn es wieder so ein Frickelwerk ala VCL-Portierung geworden wäre, würdet ihr euch spätestens in ein paar Monaten darüber aufregen.

Viele Grüße,
Florian

[mquadrat]

Zitat:

Zitat von Stevie (Beitrag 1117204)

Ich bin mal gespannt, wie sehr dieses Bewusstsein in der Delphi Community insgesamt Einzug halten wird. Sprich 1mal Businesslogik implementieren und xmal Oberflächen für verschiedene Plattformen und Anwendungsgebiete und dann zusammen stecken. Insgesamt ein Vorgehen, was viele Vorteile bringt.

Man müsste halt mal das Fisch-Beispiel als MVVM implementieren :D

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1117423)

Zitat:

Zitat von Stevie (Beitrag 1117204)

Ich bin mal gespannt, wie sehr dieses Bewusstsein in der Delphi Community insgesamt Einzug halten wird. Sprich 1mal Businesslogik implementieren und xmal Oberflächen für verschiedene Plattformen und Anwendungsgebiete und dann zusammen stecken. Insgesamt ein Vorgehen, was viele Vorteile bringt.

Man müsste halt mal das Fisch-Beispiel als MVVM implementieren :D

Gute Idee :thumb:

[QuickAndDirty]

Zitat:

Zitat von mkinzler (Beitrag 1117412)

Zitat:

Ich weiß nicht ...
mit Morfik kann ich alle Plattformen und HandyPlattformen und das Internet beliefern...mit einem einzigen Code...

Die Portierung nach Morfik dürfte sich aber um einiges komplexer gestalten als der Umsteig von einer VCL zu einer FMX-Oberfläche. (Wenn bei Morfik natürlich auch Pascalsyntax möglich ist)

Ja die Portierung wäre Wahnsinn!!! Aber Neue Programme vor allem eben Web und Mobile kann man sehr gut mit Morfik machen. Und ja Morfik ist mit Object Pascalcode , C# und VB Code Programmierbar
und zwar Browserseitig und Serverseitig (javacode unterstützung ist kostenplichtig)...es ist auch möglich serverlos zu entwickeln.(aber nur für kleine spielereien). Es hat Theming integriert webservices und Datenbank...Ich finde es halt ziemlich überzeugend. Arbeite damit privat sehr gerne.

Zitat:

Zitat von mkinzler (Beitrag 1117412)

Grundsätzlich finde ich es komisch, dass seit Jahren gemeckert wird, dass sich bei Delphi nichts tut und jetzt wird gemeckert, dass dafür Änderungen im Code notwendig sind, was ja nicht unbedingt der Fall ist. Nur wenn man für mehrere Plattformen entwicklen will; die VCL ist nunmal zu sehr mit der WinAPI verzahnt, dass eine Portierung sinnvoll/möglich wäre.

Ja so sind wir...
Im ernst ich finde es gut, wenn man etwas umstellen KANN was man umstellen möchte. Aber nicht wenn man MUSS.
64Bit ist z.B. ein gutes Verkaufsargument da lohnt sich eine Umstellung! Weil Kunden das als Feature wahrnehmen.
Unicode fähig ist eher kein Verkaufsargument wenn mann nicht sehr "Asiatisch" aufgestellt ist. Und wenn ich dann auf Unicode umstellen MUSS ist das eben verschwendete Zeit.
FireMonkey Portierung ist z.B. durchaus ok, weil man damit ein bisher kaum erschlossenes Marktsegment beackern kann...man hat somit eine Umstellung die begründbar ist.
(Firemonkey WPF kompatibel zu machen wäre noch cooler gewesen...Vielleicht gibts ja sowas wie Firemonkey Plugin für Expression Blend oder einen WPF-FMX-Konverter)
Umstellen des Reporting tools ist sicher für kaum einen Kunden ein Feature...vor allem wenn es nicht 100% kompatibel ist. 99% Kompatibilität sind ja immernoch blöd wenn der Kunde das Umstellen seiner schon längst erworbenen spezial Berichte auch noch bezahlen soll.

Es ist also wirklich eine Unart das Probleme die schon x-mal gelöst wurden immer und immer wieder erneut gelöst werden müssen.

[QuickAndDirty]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1117417)

Und wer gibt die Garantie, dass Morfik nicht in den kommenden Jahren / Monaten eingestellt wird oder die Syntax komplett umgestellt wird?

Es ist recht unwahrscheinlich, weil es ja gerade mit der Syntax kompatibilität werben.
(und fpccode und javascript code als intermediate code benutzt)
Aber die selbe Garantie bekommt man auch von Embarcadero nicht!

Das es Eingestellt wird ist realtiv unwahrscheinlich da Altiums ein Portal auf basis von Morfik in Arbeit hat und Morfik gehört Altium! Allerdings sind Updates in nächster Zeit deswegen eher verzögert.
Eine neue Version kommt erst wenn das neue AltionPortal fertig ist.

[stahli]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117498)

Unicode fähig ist eher kein Verkaufsargument wenn mann nicht sehr "Asiatisch" aufgestellt ist. Und wenn ich dann auf Unicode umstellen MUSS ist das eben verschwendete Zeit.

Im Normalfall war doch eine Anpassung ruck zuck erledigt und überhaupt die einzige unkompatible Delphi-Änderung bisher.

Wer "spezielle" Projekte in arbeit hatte, die schwer auf Unicode umzustellen waren kann ja für dieses Objekt sein altes Delphi weiter nutzen.

Ich würde diesbezüglich Emba nix vorwerfen. Im Gegenteil hielte ich auch mal eine runderneuerte VCL durchaus für angebracht (und würde für deutliche Besserungen sogar einen kompletten Kompatibilitätsbruch in Kauf nehmen) - mal sehen, wieweit hier XE2 in der Praxis geht...

Ob FireMonkey tauglich für "normale Windows-Desktopanwendungen" ist, da bin ich etwas skeptisch, aber erst mal Tee kochen und abwarten (oder so ähnlich) ;-)

[QuickAndDirty]

Zitat:

Zitat von stahli (Beitrag 1117515)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117498)

Unicode fähig ist eher kein Verkaufsargument wenn mann nicht sehr "Asiatisch" aufgestellt ist. Und wenn ich dann auf Unicode umstellen MUSS ist das eben verschwendete Zeit.

Im Normalfall war doch eine Anpassung ruck zuck erledigt und überhaupt die einzige unkompatible Delphi-Änderung bisher.

Wer "spezielle" Projekte in arbeit hatte, die schwer auf Unicode umzustellen waren kann ja für dieses Objekt sein altes Delphi weiter nutzen.

Ich würde diesbezüglich Emba nix vorwerfen.

Ich werfe Embarcadero nichts vor. Obwohl das mit der Unicode änderung wenn wir sie dann machen ...also wenn D2007 und D7 bei uns in pension gehen....bzw. mal sehen was mit Win8 kommt...
Aber es wäre auf jedenfall eine umstellung die keinen wirklich Mehrwert beim Kunden erzeugt.

Zitat:

Zitat von stahli (Beitrag 1117515)

Im Gegenteil hielte ich auch mal eine runderneuerte VCL durchaus für angebracht

Warum?

Zitat:

Zitat von stahli (Beitrag 1117515)

(und würde für deutliche Besserungen sogar einen kompletten Kompatibilitätsbruch in Kauf nehmen) - mal sehen, wieweit hier XE2 in der Praxis geht...

Finde es durch aus praktisch das sie beide Oberflächen unterstützen und einem eben nicht wieder umstellungsarbeiten aufzwingen...wobei Firemonkey ja kein ersatz für die VCL ist sondern für sich als feature gewertet werden darf, da das Umstellen auf FireMonkey ja einen Mehrwert generiert... Multiplatformfähigkeit eben!

Zitat:

Zitat von stahli (Beitrag 1117515)

Ob FireMonkey tauglich für "normale Windows-Desktopanwendungen" ist, da bin ich etwas skeptisch, aber erst mal Tee kochen und abwarten (oder so ähnlich) ;-)

User ertragen ja auch Swing und das Adobe Flex zeug oder Silverlight und Javafx....
Das einzige problem dürfte doch sein das es entweder wie eine "Delphi Anwendung" aussehen wird wenn man FireMonkey mit den bestandskomponenten nimmt oder
Es wird NICHT wie eine "Standard Anwednung" aussehen...also gescinned...und das kommt immer entweder total oder garnicht an!
Ich persönlich bin ja eher der Anhänger von Anwednungen die sich ins look and Feel des Desktops perfekt integrieren...von daher hoffe ich auf ein Default Style und Theme welches das Look And Feel von dem Desktop auf dem es sich befindet perfekt mimiked.

[stahli]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117526)

Zitat:

Zitat von stahli (Beitrag 1117515)

Im Gegenteil hielte ich auch mal eine runderneuerte VCL durchaus für angebracht

Warum?

Ich hatte das schon mal irgendwo begründet...

Die Controls sollten m.E. einheitlichere und sinnvollere Ereignisbehandlungen erhalten und ableitungsfreundlicher sein (generell virtuelle Methoden enthalten und protected Felder.

Der erste Punkt würde die Nutzung verbessern (OnClick sollte bei einem Klick aufgerufen werden, OnChanged bei einer Wertänderung etc).
Der zweite Punkt würde eine Entwicklung abgeleiteter Komponenten vereinfachen.
Paint könnte z.B. PaintBackground und dann PaintData aufrufen. So kann man wahlweise eine der Methoden überschreiben.

TRadioGroup hat als schlechtes Beispiel wohl schon einige zur Verzweiflung getrieben, wenn man ein paar Feinheiten realisieren wollte...

ParentBackground ist ja auch eher in die alten Controls "reingepresst", würde ich mal denken. Ich könnte mir vorstellen, dass eine komplette Überarbeitung mal sinnvoll sein könnte (vielleicht löst sich ja auch schon einiges mit XE2 (VCL und/oder FM)).

Inwieweit man sich zu diesem Zwecke von der Windows-API (oder was auch immer hier genau genutzt wird) lösen kann und sollte, vermag nicht nicht zu beurteilen. Ich würde mir halt nur grundsätzlich einige Verbesserungen wünschen.

[mquadrat]

An onClick / onChange hat sich die ganzen Jahre keiner dran getraut, da wird sich nun auch nichts mehr ändern.

[mkinzler]

Bei VCL definitv nicht. Bei FMX könnte das schon sein.

[QuickAndDirty]

Zitat:

Zitat von stahli (Beitrag 1117534)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117526)

Zitat:

Zitat von stahli (Beitrag 1117515)

Im Gegenteil hielte ich auch mal eine runderneuerte VCL durchaus für angebracht

Warum?

Ich hatte das schon mal irgendwo begründet...

Die Controls sollten m.E. einheitlichere und sinnvollere Ereignisbehandlungen erhalten und ableitungsfreundlicher sein (generell virtuelle Methoden enthalten und protected Felder.

Der erste Punkt würde die Nutzung verbessern (OnClick sollte bei einem Klick aufgerufen werden, OnChanged bei einer Wertänderung etc).
Der zweite Punkt würde eine Entwicklung abgeleiteter Komponenten vereinfachen.
Paint könnte z.B. PaintBackground und dann PaintData aufrufen. So kann man wahlweise eine der Methoden überschreiben.

TRadioGroup hat als schlechtes Beispiel wohl schon einige zur Verzweiflung getrieben, wenn man ein paar Feinheiten realisieren wollte...

ParentBackground ist ja auch eher in die alten Controls "reingepresst", würde ich mal denken. Ich könnte mir vorstellen, dass eine komplette Überarbeitung mal sinnvoll sein könnte (vielleicht löst sich ja auch schon einiges mit XE2 (VCL und/oder FM)).

Inwieweit man sich zu diesem Zwecke von der Windows-API (oder was auch immer hier genau genutzt wird) lösen kann und sollte, vermag nicht nicht zu beurteilen. Ich würde mir halt nur grundsätzlich einige Verbesserungen wünschen.

SOOO Große Änderungen....ok
dann habe ich auch etwas was ich gerne hätte und nie bekommen werde....
Jede VCL Komponente und Control sollte eine vollständige Interface Impelemtierungen sein und sich auch Gegenseitig über Interfaces referenzieren! Das muss insbesonderer für TDataset , TDatassource (Tdatalink)und alle DBControls gelten.

Warum? Wegen Dll Kompatibilität und wegen der total bekloppten Umständlichkeit die man zum Teil hat um eigene Datasets abzuleiten!

[mquadrat]

@QuickAndDirty

Mit der neuen Datenbindung wird das doch sowieso obsolet, oder nicht?

[Bernhard Geyer]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117547)

Warum? Wegen Dll Kompatibilität ..

Wir mit sicherheit nicht kommen. Willst du wohl DLL's mit lebenenden Objekten haben ohne gemeinsame Laufzeitpackages zu verwenden?

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1117568)

@QuickAndDirty

Mit der neuen Datenbindung wird das doch sowieso obsolet, oder nicht?

Wer's glaubt...

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1117578)

Zitat:

Zitat von mquadrat (Beitrag 1117568)

@QuickAndDirty

Mit der neuen Datenbindung wird das doch sowieso obsolet, oder nicht?

Wer's glaubt...

Da er hier den Futur benutzt, ist die Aussage faktisch nicht zu widerlegen.

[QuickAndDirty]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1117574)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117547)

Warum? Wegen Dll Kompatibilität ..

Wir mit sicherheit nicht kommen. Willst du wohl DLL's mit lebenenden Objekten haben ohne gemeinsame Laufzeitpackages zu verwenden?

^^

Sorry ich bin einer von dieser Sorte. Ja!
Und wo gerade Wunschlisten gedruckt werden.....

[QuickAndDirty]

Zitat:

Zitat von mquadrat (Beitrag 1117568)

@QuickAndDirty

Mit der neuen Datenbindung wird das doch sowieso obsolet, oder nicht?

Davon habe ich noch garnichts gelesen...
Hast du nen Link mit gerüchten??? oder fakten?

Edit:
Viele meinen es sei sowas wie die "bind" oder trigger deklaration bei Javafx...
quasi

TMyClass = class
a:integer bind b*2;
b:integer;
end;

könnte das gemeint sein? weil das ist für Animationen durchaus sehr wichtig

oder sowas ?
http://msdn.microsoft.com/en-us/libr...x#Data_Binding


Ja...es is sowas wie das cocoa,JavaFX und wpf binding...
Was man halt so für MVVM modelle braucht.

[mkinzler]

Es gibt eine neue art von Datenanbindung für jedes Control (live binding)
http://delphi-insider.blogspot.com/

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1116983)

Zitat:

Zitat von Stevie (Beitrag 1116949)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1116924)

Das wäre die Frage: Ist eine Mixed-Betrieb zwischen VCL und FireMonkey möglich?

Nein, entweder deine Anwendung ist VCL, oder sie ist FireMonkey.

Das ist aber besch****. Also entweder oder? Ich hoffe auf ein ähnliche Unit wie bei VCL2NET in der Mischbetrieb .NET und VCL.NET möglich war.

"Relativ bald" nach dem Release von XE 2 wirds eine neue Hydra-Version geben die FireMonkey unterstützt. Das heisst dann FireMonkey in VCL, in WPF, in Windows Forms und natürlich jeweils auch in alle Richtungen zurück. Also Windows Forms oder VCL freilich auch in FireMonkey.

[neo4a]

In diesem Blog-Eintrag wird das Live-Binding noch etwas expliziter erklärt. Als Service hier die Stelle übersetzt:

Zitat:

Aber was ist mit DataAware-Controls? Hat FireMonkey zumindest jene?

Nein.

Stattdessen haben wir jetzt LiveBindings. Diese sind nicht auf FireMonkey beschränkt – LiveBindings funktionieren in allen Delphi-Code-Bereichen, alte VCL genauso wie FireMonkey.

Einfach ausgedrückt, LiveBindings ist eine Verbindung zwischen zwei Eigenschaften auf einzelne Objekte. So können Sie zum Beispiel binden "Caption"-Eigenschaft eines TLabel zum "DisplayName" einer TDBColumn.

Aber diese sind nicht einfach nur Eigenschaft-zu-Eigenschaft- Zuordnungen. LiveBindings haben einen auch einen Konverter der gebundenen Eigenschafts- Werte, so könnte man das Label binden Beschriftung Eigenschaft auf den Ausdruck ""Column Name ist: '+ Großbuchstaben (DisplayName)"Zum Beispiel. Offensichtlich ist eine solche Bindung unidirektional - Sie könnten es verwenden, um das Label Beschriftung den Namen der Spalte gesetzt, aber man konnte nicht verwenden, um den Namen der Spalte auf dem Etikett zu aktualisieren, da es keine Möglichkeit gibt, einfach den Ausdruck zurück zu übersetzen.

Aber wo eine einfache Eigenschaft-to-Eigenschaftenbindung erstellt wird, werden diese - oder können (Sie entscheiden) - bidirektional.

...

Sie wollen den Wert des ausgewählten Elements in einem Listenfeld im Dialogfeld Beschriftung angezeigt werden? Auf geht's, ein Binding.

Und als Bonus kan der Evaluator/Konverter für die LiveBindings auch stand-alone eingesetzt werden, um jeden ObjectPascal Ausdruck auszuwerten, dynamisch zur Laufzeit.

Und wer nicht warten möchte bis XE2 verfügbar ist, der schaut sich einmal Stevies DSharp-Projekt an, das das schon alles kann.

[Chemiker]

Hallo,

ich muss gestehen, dass ich von FireMonky vor 1 Monate noch nichts gewusst habe. Was sie können oder nicht können ist mir nicht bekannt. Das FireMonky aus Russland kommt stört mich nicht ist setzte auf FIBPlus ein, die Komponenten kommen auch aus Russland.

Meine Frage ist aber, ab welche Version stehen die Neuerungen zur Verfügung, die meisten Beiträge hier sind von Delphi-Benutzer geschrieben die die Prof.-Version einsetzen. Wenn das so geht wie die Firebird Unterstützung bei Delphi 2009, dann kann man sie erst mit den großen Versionen einsetzen.

Bis bald Chemiker

[jaenicke]

Auch die Starter Edition, die parallel mit den anderen kommt, beinhaltet alle Plattformen und damit auch FireMonkey.

// EDIT:
Da hat dann wohl jemand etwas falsch verstanden. Man sollte eben doch nicht alles glauben was jemand schreibt, egal wie glaubwürdig es klingt. ;-)

[himitsu]

Zitat:

Zitat von mquadrat (Beitrag 1117541)

An onClick / onChange hat sich die ganzen Jahre keiner dran getraut, da wird sich nun auch nichts mehr ändern.

Mein Kolege ist heute uf die CheckBox-Flle reingefallen.

OnClick wird ausgelöst, wenn man im Programmcode den Checked-Status ändert. :lol:
Hatte er nicht erwartet.

[Luckie]

Bei denen vielen Neuerungen, ziehe ich die Konsequenz, dass ich zu alt geworden bin und setze mich zur Ruhe. :roll:

[MEissing]

Zitat:

Zitat von Chemiker (Beitrag 1117624)

Meine Frage ist aber, ab welche Version stehen die Neuerungen zur Verfügung, die meisten Beiträge hier sind von Delphi-Benutzer geschrieben die die Prof.-Version einsetzen. Wenn das so geht wie die Firebird Unterstützung bei Delphi 2009, dann kann man sie erst mit den großen Versionen einsetzen.

Das ist zur Zeit noch nicht offiziell bekannt gegeben.

Was da in welchen Editionen drin ist überlasse ich meiner Festplatte (die schweigt wie ein Grab :lol: , auch, weil es eine SSD ist) oder den wilden Spekulationen. Ob die Starter dann auch x64 unterstützt, FireMonkey, Mac OS X, iOS.... ich glaube ich nehme dann mal Urlaub, wenn's offiziell geworden ist (zumindest lass ich mich dann hier nicht mehr blicken).

Heute ist der 17. August. Zeit das schöne Wetter zu geniessen....

[MEissing]

Zitat:

Zitat von jaenicke (Beitrag 1117638)

Auch die Starter Edition, die parallel mit den anderen kommt, beinhaltet alle Plattformen und damit auch FireMonkey.

Sagt wer?

Eine belastbare Quelle wäre interessant....

[mkinzler]

Ich hoffe nicht, das die neuen Features nur in bestimmten Ausgaben vorhanden sind. Ich glaube auch nicht, dass dies besonders förderlich für den Verkauf wäre. Die wenigsten werden die Enterprise/Architekt wegen FireMonkey kaufen.