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

[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.