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

[Bernhard Geyer]

Zitat von QuickAndDirty:

Es scheint aber auch ohne unicode und mit codepage in englisch, spanisch, polnisch, tschechisch und sogar in Kyrilsch/Russisch zu funktionieren...

Na dann versuch mal den Datenbestand der auf dem dortigen System anfällt hier anzuzeigen.
Oder wenn ein Russischer Kunde auf die Idee kommt ein "Ä" einzugeben.

Also auf den entsprechenden Windows-Versionen kann man die entsprechende Zeichen auch in Ansi-Delphi verwenden. Und deinen Russischen Kunde stört es scheinbar nicht das die hälfte der Zeichen ihre Sprache nicht gehen.

[QuickAndDirty]

Zitat von Bernhard Geyer:

Zitat von QuickAndDirty:

Bin ich der einzige der das sinnvoll findet? Oder ist es einfach zuviel Arbeit und von daher sehr unwahrscheinlich?

Es gibt ein Lösung: Laufzeitpackages verwenden. Und nur dadurch kann sowas sinnvoll realisiert werden wenn nur ein Laufzeitumgebung für Exe+DLL zuständig ist. In .NET und Java ist es genauso. Man kann hier (AFAIK kann man es mit viel aufwand für Java) nicht einfach einen Teil in Java 6 laufen lassen und dann einzelne JAR-Files mit Java 5.

Und die VCL soweit umzubauen das man alles mit Interfaces machen kann heißt eigentlich einen kompletten Rewrite durchzuführen. Die kompatiblität mit bestehender SW wäre natürlich ziemlich dahin. Dann ist es einfach ein neues Framework (wie gemacht) zu entwickeln um hier auf "grüner Wiese" anfangen zu können und nicht bei jeder 2ten Codezeile klar zu sein das man hier wieder ein paar Entwickeler zum fluchen bringt. Wenn man bei neueren Delphi-Verisionen betrachtet wie die Umstellung der MainForm wegen Vista/Win7 für Auswirkungen hatte sollte klar sein was ein Infaceumbau bedeuten würde.

Ich sage ja ...wenn sowie so alte Zöpfe abgeschnitten werden. Und man auch gerne dafür inkompatibilitäten in kauf nähmme....DANN würde ich mir vollständig Interface implementierte und referencierte VCL Klassem wünschen.

Was haben die mit der Mainform den gemacht? Weil die d7 und 2007 Mainform läuft doch gut unter Vista und Win7 ? Musstte man da was dran tun?

[Bernhard Geyer]

Zitat von QuickAndDirty:

Ich sage ja ...wenn sowie so alte Zöpfe abgeschnitten werden. Und man auch gerne dafür inkompatibilitäten in kauf nimmte....DANN würde ich mir vollständig Interface implementierte und referencierte VCL Klassem wünschen.

Und ein Garbage-Kolleger wäre auch schön ...

Zitat von QuickAndDirty:

Was haben die mit der Mainform den gemacht? Weil die d7 und 2007 Mainform läuft doch gut unter Vista und Win7 ? Musstte man da was dran tun?

Es geht darum was für Fenster angezeigt wird wenn man in Vista/Win7 über die Taskleiste die Maus bewegt. Hier musste was geändert werden damit auch die richtige Vorschau kommt wenn die Delphi-App minimiert ist. Und bei einige Entwicklern gabs hier Probleme.

[QuickAndDirty]

Zitat von Bernhard Geyer:

Zitat von QuickAndDirty:

Ich sage ja ...wenn sowie so alte Zöpfe abgeschnitten werden. Und man auch gerne dafür inkompatibilitäten in kauf nimmte....DANN würde ich mir vollständig Interface implementierte und referencierte VCL Klassem wünschen.

Und ein Garbage-Kolleger wäre auch schön ...

In der tat. Aber dann einer der konsequent funktioniert und nicht so ein Dingen wie in .NET wo es gefühlt eine millionen Ausnahmen gibt wo der nicht richtig funktioniert.(Events manuell unhooken, manche externe ressourcen manuell disposen ODER closen aber man weiß nicht zwingend was von beidem...&c.)

bzw...er sollte mit manuellen "Free" befehlen zurecht kommen oder noch besser: Die Buchhaltung die er sowieso schon macht nutzen um bei einem manuellem free alle referenzen zu NIL-en...

Also irgendwie bekomme ich gerade wirklich spaß daran mir sowas wie eine wunsch VCL zu bauen...

Wenn ich bedenke wie cool es alleine wäre auf Packages verzichten zu können und das ganz gehampel mit in packages enthaltenen Packages je nach Compilier reihen folge....


Und das mit den Fluchenden Programmierern....wegen inkompatibilitäten und so...(also so welche wie ich)
Soviele sorgen muss man sich da garnicht machen...
Einfach mal rüber nach Microsoft gucken...was die mit ihren VB6 kunden gemacht haben....lol

[Bernhard Geyer]

Zitat von QuickAndDirty:

bzw...er sollte mit manuellen "Free" befehlen zurecht kommen oder noch besser: Die Buchhaltung die er sowieso schon macht nutzen um bei einem manuellem free alle referenzen zu NIL-en...

Dazu braucht man kein GC. Einfach sich als Listener beim Control eintrag und man bekommt ein Event wenn das Control freigegeben wird. Macht die VCL genauso. Jedoch kennen das die wenigsten. Ansonsten wäre es im Bereich Managed Umgebung eine weak reference.

[QuickAndDirty]

Zitat von Bernhard Geyer:

Zitat von QuickAndDirty:

bzw...er sollte mit manuellen "Free" befehlen zurecht kommen oder noch besser: Die Buchhaltung die er sowieso schon macht nutzen um bei einem manuellem free alle referenzen zu NIL-en...

Dazu braucht man kein GC. Einfach sich als Listener beim Control eintrag und man bekommt ein Event wenn das Control freigegeben wird. Macht die VCL genauso. Jedoch kennen das die wenigsten. Ansonsten wäre es im Bereich Managed Umgebung eine weak reference.

ja aber wenn du viele refernzen in vielen units hast...willst du das doch nicht per hand machen...
Und nicht nur controls...sondern Objecte aller art sollten ja funktionieren.
Meinst du mit Listener die FreeNotification Geschichte? Oder etwas von dem ich noch nie gehört habe?

[Bernhard Geyer]

Zitat von QuickAndDirty:

ja aber wenn du viele refernzen in vielen units hast...willst du das doch nicht per hand machen...
Und nicht nur controls...sondern Objecte aller art sollten ja funktionieren.

Will man eigentlich nicht. Aber bevor alle Klassen mit Interfaces gemacht werden dann gleich auf GC+Managed Umgebung gehen.

Zitat von QuickAndDirty:

Meinst du mit Listener die FreeNotification Geschichte? Oder etwas von dem ich noch nie gehört habe?

Ist schon FreeNotification

[QuickAndDirty]

Zitat von Bernhard Geyer:

Zitat von QuickAndDirty:

ja aber wenn du viele refernzen in vielen units hast...willst du das doch nicht per hand machen...
Und nicht nur controls...sondern Objecte aller art sollten ja funktionieren.

Will man eigentlich nicht. Aber bevor alle Klassen mit Interfaces gemacht werden dann gleich auf GC+Managed Umgebung gehen.

och ich mag so native sachen...schon allein von der distribution her...und da ergäben sich ja mit DLLs riesige Vorteile was live bugfixes angeht z.B.

[stahli]

Zitat von QuickAndDirty:

bzw...er sollte mit manuellen "Free" befehlen zurecht kommen oder noch besser: Die Buchhaltung die er sowieso schon macht nutzen um bei einem manuellem free alle referenzen zu NIL-en...

Da lag ich ja mit meinem Thema doch nicht so daneben...
http://www.delphipraxis.net/159095-r...e-objekte.html

Innerhalb meiner Komponenten funktioniert das inzwischen tadellos.
Z.B. wird ein Edit-Zeiger auf Edit->Person.Firstname automatisch auf nil gesetzt, wenn "Person" freigegeben wird.
Dazu werden alle "überwachten" Objekte in einer zentralen Liste gespeichert, aus der sie sich bei Ihrer Freigabe wieder löschen. Zuvor werden per RTTI auch noch Referenzen auf dieses Objekt gesucht und auf nil gesetzt.

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.

[QuickAndDirty]

Na dazu kann ich noch etwas selbst kritik liefern...so garbagecolletions und Referenzzähler haben es natürlich schwer wenn man mit gecasteten Zeigern arbeitet...
dürfte schwer sein ein object das ich in einen Integertyp gecastet habe zu Nil-en. Oder eine als string gespeicherte referenzadresse....
Schmutzige Tricks müssen aber eben auch bestraft werden!