Delphi XE8 im Anmarsch...

[Bernhard Geyer]

Zitat von jaenicke:

Zitat von Insider2004:

Delphi 7 war maximal stabil und ausgereift.

Hatte aber auch jede Menge Bugs, z.B. den Fensterrahmen Bug, Beispiel siehe hier:
http://www.entwickler-ecke.de/viewto...=691676#691676

Das ist aber ein VCL und kein IDE-Bug. Liegt daran das früher Width und Heigth für das Formular gespeichert wurde. Jetzt wird korrekterweise ClientWidth und ClientHeight gespeichert so das die dicke des Fensterrahmens (das sich mit jeder Windows-Version ändert) nicht mehr stört.

[p80286]

Zitat von Bernhard Geyer:

Das ist aber ein VCL und kein IDE-Bug. Liegt daran das früher Width und Heigth für das Formular gespeichert wurde. Jetzt wird korrekterweise ClientWidth und ClientHeight gespeichert so das die dicke des Fensterrahmens (das sich mit jeder Windows-Version ändert) nicht mehr stört.

Sogar Klatsch und Tratsch ist informativ, jetzt wunder' ich mich auch nicht mehr.

Gruß
K-H

[Insider2004]

ja, beim Kaffeekränzchen gibt's die Insider-Infos!

[himitsu]

Und passend dazu werden Größenbeschränkungen nicht richtig auf Anchors angewendet, vorallem nicht akRight und akBottom.

Wenn durch die Rahmenbreite oder durch den Desktop (Programm in FullHD ganz groß entwickelt und Fenster nun z.B. in 15"-1024x768 geladen)

Dann ist das Fenster fu klein, und die Komponenten werden außerhalb platziert, da Delphi garnicht bemerkt (nicht drauf achtet), daß das Fenster zu klein ist und Komponenten dennoch Pixelgenau da platziert, wo es gespeichert wurde.

[Insider2004]

Dann musst du halt auch deine Kompos mit akRight versorgen.

[himitsu]

Nein. Wenn man das Fenster zur Laufzeit in der Größe verändert, wird alles "richtig" im selben Maße mit vergrößert/verkleinert/verschoben.

Wenn das aber bereits beim Erstellen, von Windows, beschränkt wird, dann liegen die Komponenten verschoben auf der Form und bleiben dort dann auch liegen, bzw. werden nur relativ zum Rahmen mit verschoben.
Das kann einmal an einem zu kleinem Monitor liegen, oder an breiteren Rahmen oder es passiert auch gerne beim Zoom des Desktops.

Ich hab noch ein altes D7-Programm im Einsatz, wo leider der Quellcode nicht mehr funktionsfähig kompilierbar ist.
In der alten und bereits kompilierten EXE liegen nun ein paar Buttons rechts auserhalb des Fensters, wenn ich das Programm auf'm Schlepptop starte, der mal mit 'ner 125%-Schrift eingerichtet war.

Leider gibt es da einen Bug, wodurch schrottige D7-Programme und Java-Programme (selbst der aktuelle JavaRE-Installer) immernoch denken es seien 125% und dann die Fenster falsch ausrichten.

[Delbor]

Hi zusammen

Tja, mich interessiert eigentlich in erster Linie mal, wie das mit dem Updatepfad so ausschaut. Aktuell arbeite ich mit XE4. Ein Update auf das aktuelle DelphiXE7 ist laut meinem Händler ab XE2 möglich; also müsste ich wohl spätestes auf XE9 updaten, nehm ich an. Ob das aber stimmt, weiss ich nicht.
Ursprünglich waren ja m.W. Updatezyklen von 3 Jahren vorgesehen - aufgrund der aktuellen Entwicklung sind die aber massiv geschrumpft.
Da werde ich mich wohl überraschen lassen müssen...

Gruss
Delbor

[himitsu]

XE6 war auch schon ab XE2 möglich ... drum hatte ich bei XE7 eigentlich mit XE3 gerechnet, aber vermutlich/bestimmt hat sich das Ganze etwas verschoben, da es ja nun halbjählich eine neue Version gibt.
Ursprünglich waren es mal die letzten 3 Vorgänger-Versionen (nun somit 6) ... XE2 müsste also rein rechnerisch auch noch für XE8 gelten und dann wieder weiterzählen, oder jetzt kommt zwei Mal XE3 dran.


ABER, es gibt praktisch IMMER, mindestens einen Monat lang (gefühlt insgesamt mindestens zwei bis drei) ein "Sonderangebot", wo man Gratiszeugs (Zusatzprogramme, PDFs usw.) dazu bekomm und dabei auch noch von jeder Vorgängerversion Upgraden kann.
(Seit der damaligen Einführung 'ner gewissen "Raubkopierer"-Sonderaktion, wurde dieses "Du darfst von allen Delphis upgraden"-Sonder-Spezial IMHO noch nie ausgelassen)

XE4 + 2 * 3 = XE10


PS: Für die Starter-Editionen ist man praktisch immer upgradeberechtigt. Unabhängig von irgendeiner Delphi-Version, welche man hat oder nicht, da hier auch andere IDEs (QBasic, Lazarus, Netbeens, Visual Studio, Notepad++ usw.) als Upgravorausetzung gelten. (damit will natürlich niemand nicht behaupten, daß die Starter-Vollverion eine reine Abzocke darstellt) :

[sahimba]

Zitat von Delbor:

aufgrund der aktuellen Entwicklung sind die aber massiv geschrumpft.

Insbesondere erspart sich Embarcadero damit, Servicepacks auszuliefern, um die IDE endlich einmal wieder zu stabilisieren. Das Thema "Out of Memory" zieht sich nun über mehrere Releases und wurde zunehmend kritischer. Erst mit XE7 scheinen die das langsam in den Griff zu bekommen, derart fundamentale Dinge zu fixen. Dafür kommen nun neue Fehler hinzu ("Interner Fehler MA330") (*), das es ein Graus ist. Ich arbeite seit 15 Jahren mit Delphi und ich liebte es. Was aber in letzter Zeit abgeliefert wird, ist nur noch zum Haare raufen und... *selbstzensur*
"Mit der nächsten Version wird alles besser"... die Hoffnung stirbt nicht zuletzt sondern im 6-Monats-Takt.
Und ja: ich bin angefressen.

(*) Ja... es gibt einen Jira-Eintrag...

[jaenicke]

Zitat von sahimba:

Das Thema "Out of Memory" zieht sich nun über mehrere Releases und wurde zunehmend kritischer.

Ich fürchte das wird erst gelöst sein, wenn die IDE 64-bittig ist...
Denn es sind dafür ja nicht nur Speicherprobleme verantwortlich, sondern es wird schlicht sehr viel Speicher benutzt.
Ich fürchte allerdings, dass im Falle eines Umstiegs auf 64-Bit die Speicherlecks noch weniger Beachtung finden werden...

Zitat von sahimba:

Erst mit XE7 scheinen die das langsam in den Griff zu bekommen, derart fundamentale Dinge zu fixen.

Das ist bisher die instabilste Version überhaupt, zumindest bei uns. Dreimal kompilieren (ohne Addons, ohne alles), Out of Memory...
Allerdings scheint das Problem nun endlich stärkere Beachtung zu finden, den Eindruck habe ich auch.

Zitat von sahimba:

Dafür kommen nun neue Fehler hinzu ("Interner Fehler MA330") (*), das es ein Graus ist.

Ja, ich habe einige Stunden gebraucht um die Stellen im Quelltext zu finden, erst in unseren Komponenten, dann im Programm selbst... Und die Workarounds sind nicht schön...
Eine generische Klasse, die per Funktion in der selben Unit mit einem konkreten Typ versorgt werden muss, so dass nach außen nix mehr generisch ist...

Das erinnert mich an Klassenvariablen, die damals bei Delphi 2005 oder 2006 auch nur in derselben Unit ansprechbar waren, sonst gab es einen internen Fehler.