Reise von Berlin nach Athens

[SearchBot]

Hi,

ich bekomme von meiner Firma jetzt das Athens 12.1 Professional gestellt, damit wir auch in Windows 11 weitermachen können.
Bislang (seit 2016) arbeite ich auf 10.1 Berlin Prof. noch auf Windows 10 (zuhause habe ich Tokyo)

Was muss ich bei dem Umstieg von Berlin nach Athens beachten, damit es nach Möglichkeit reibungslos gelingt?

- muss ich Berlin zuerst komplett deinstallieren?
- kann ich meine Einstellungen migrieren oder muss ich alles neu einrichten?
- besser von der ISO installieren oder vom Webinstaller?
- wieviel GB für Delphi (also nicht RAD) werden es am Ende der Installation sein (Partition sollte ja groß genug sein)

Welche Stolperfallen gibt es noch?

[jsheyer]

Hi,

Wenn keine Fremdkomponenten im Spiel sind ist der Wechsel problemslos zu berwerkstelligen.
Und die Installation der 12.1 Version kann parallel zu Deiner bestehenden 10.1 Version erfolgen.
Ich persönlich nehme immer den Web Installer.
Was den Speicherverbrauch der Installation betrifft hängt das von der Auswahl während der Installation ab, wenn z.B. das Android SDK mit installiert sind das ja schon ein paar GB.
Das Setup zeigt die aber bei der Auswahl sofort an wieviel Plattenplatz benötigt wird.

[SearchBot]

Zitat:

Zitat von jsheyer (Beitrag 1539903)

Hi,

Wenn keine Fremdkomponenten im Spiel sind ist der Wechsel problemslos zu berwerkstelligen.

Ah, schon ein paar - du meinst welche, die nicht über das Get-Tool zu bekommen sind? - FastReports?

Zitat:

Und die Installation der 12.1 Version kann parallel zu Deiner bestehenden 10.1 Version erfolgen.

Also kann ich bei einem Athens-Problem auch normal mit Berlin weitermachen? Das wär ja prima - ich hatte noch im Kopf, daß es parallel nicht möglich wäre. Dann wurde das inzwischen verbessert.
Einen Ordner mit gemeinsamen (Fremd-)Komponenten, Units wäre dann auch möglich - oder besser trennen?

Danke schon mal.

[jsheyer]

FastReport ist kein Problems, du musst das passende Setup haben.

Das mit dem Parallel Betrieb ist schon lange möglich, nur wenn z:b. das Update von 12.1 auf 12.2 käme dann wird 12.1 deinstalliert.
Oder in Deiner alten Version von 10.1 auf 10.2, 10.3, etc. dann wird die jeweiligere 10er Version deinstalliert.
Die letzten Jahre hatte ich eigentlich keine Probleme damit.

[Uwe Raabe]

Zitat:

Zitat von jsheyer (Beitrag 1539909)

Oder in Deiner alten Version von 10.1 auf 10.2, 10.3, etc. dann wird die jeweiligere 10er Version deinstalliert.

Das ist nicht ganz richtig! Delphi 10, 10.1, 10.2, 10.3, 10.4, 11 und 12 können nebeneinander existieren (tun sie hier auch). Die 10er Reihe war ein Ausreißer, aber seit 11 ist man wieder zu vernünftigen Versionsnummern zurückgekehrt. Mal sehen wie lange das anhält...

[Papaschlumpf73]

Bei mir gab es auch immer mal Theater mit Parallel-Installationen. Vor allem bei den Drittanbieter-Komponenten. Deshalb hat bei mir jede Delphi-Version seine eigene VM. Das hat sich ganz gut bewährt.

[dummzeuch]

Wichtig: Solange Du Projekte in beiden Versionen parallel bearbeitest, ist die Property TForm.OldCreateOrder ein Problem:
* Delphi 12 löscht sie aus den DFM-Dateien und nimmt False als Default an
* Ältere Delphi Versionen erstellen sie beim Abspeichern wieder, wenn sie nicht existiert, mit OldCreateOrder=True. (Neue Formulare erstellen diese älteren Versionen mit OldCreateOrder=False.)

Das kann fatale Konsequenzen haben, denn mit OldCreateOrder=True, werden FormCreate Events ausgeführt, bevor der Constructor komplett ausgeführt wurde, wie das früher mal bei Delphi 5(?) oder sogar noch früher der Fall war.

Ich meine mich dunkel zu erinnern, dass Uwe Raabe darüber gebloggt hatte.

[himitsu]

Jupp, das bezüglich OldCreateOrder.
Bei uns D10/11 und XE.

Da Emba sich eh weigerte einen anderen Bug zu beheben,
haben wir nun also einen Hook im DFM-Reader der IDE, welcher auch das gleich behebt.



Bei z.B. Formvererbung gibt es massive Probleme,
ebenso wenn jemand im Constructor/DFM sowohl Width/Heigt als auch ClientWidth/ClientHeight setzt, denn ClientWidth/ClientHeight wird verzögert im AfterConstructor geladen, womit ein später zugewiesenes Width/Height bösartig ignoriert wird.

[SearchBot]

Zitat:

Zitat von dummzeuch (Beitrag 1539918)

Wichtig: Solange Du Projekte in beiden Versionen parallel bearbeitest, ist die Property TForm.OldCreateOrder ein Problem:
* Delphi 12 löscht sie aus den DFM-Dateien und nimmt False als Default an
* Ältere Delphi Versionen erstellen sie beim Abspeichern wieder, wenn sie nicht existiert, mit OldCreateOrder=True. (Neue Formulare erstellen diese älteren Versionen mit OldCreateOrder=False.)

Das kann fatale Konsequenzen haben, denn mit OldCreateOrder=True, werden FormCreate Events ausgeführt, bevor der Constructor komplett ausgeführt wurde, wie das früher mal bei Delphi 5(?) oder sogar noch früher der Fall war.

Ich meine mich dunkel zu erinnern, dass Uwe Raabe darüber gebloggt hatte.

Oh, danke, gut zu wissen :thumb:

Zitat:

Zitat von himitsu (Beitrag 1539919)

...
haben wir nun also einen Hook im DFM-Reader der IDE, welcher auch das gleich behebt.

Bei z.B. Formvererbung gibt es massive Probleme,...

Einen Hook? Wo bekomme ich den dann her oder wie hänge ich den rein?

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1539919)

Bei z.B. Formvererbung gibt es massive Probleme,
ebenso wenn jemand im Constructor/DFM sowohl Width/Heigt als auch ClientWidth/ClientHeight setzt, denn ClientWidth/ClientHeight wird verzögert im AfterConstructor geladen, womit ein später zugewiesenes Width/Height bösartig ignoriert wird.

Oh, das ist jetzt interessant. Seit welcher Delphi-Version ist das? Das könnte evtl. der Grund für ein Problem in GExperts sein.

[Uwe Raabe]

Dafür ist nicht zwingend ein Hook notwendig. Erstelle eine Unit mit folgendem Inhalt:

Delphi-Quellcode:

unit FixOldCreateOrder;

interface

uses
  System.Classes, Vcl.Forms;

type
  TDataModuleFix = class(TDataModule)
  protected
    procedure Loaded; override;
  end;

type
  TFormFix = class(TForm)
  protected
    procedure Loaded; override;
  end;

type
  TForm = TFormFix;

implementation

procedure TFormFix.Loaded;
begin
  inherited;
  OldCreateOrder := False;
end;

procedure TDataModuleFix.Loaded;
begin
  inherited;
  OldCreateOrder := False;
end;

end.

Diese Unit muss dann in allen Forms und DataModules als letztes in der Interface Uses-Anweisung stehen.

Im Designer steht dann zwar immer noch OldCreateOrder als True, aber das hat ja keine direkten Auswirkungen. Beim Programmstart wird das entsprechend korrigiert.

Für etwaige Abkömmlinge von TCustomActiveForm und TCustomDockForm müsste das dann entsprechend ergänzt werden.

[himitsu]

Weiß nicht genau ... frühestens im 10.2 oder vielleicht erst 11.0.
irgendwo zwischen XE und 10.4

In DFM wird ja "inzwischen" normal ClientWidth/ClientHeight gespeichert,
aber abhängig von anderen Property wird stattdessen Width/Height gespeichert (was ich teilweise für total schwachsinnig halte).
Auch andere Property haben solche abweichungen.

Und da Emba manchmal Probleme hatte, im Create auf das ClientWidth/ClientHeight zuzugreifen (Exception), wird das in einer Variable gespeichert, welcher erst im AfterConstruction angewendet wird.
Wird aber nach ClientWidth etwas an Width zugewiesen, dann wird jenes somit vom ClientWidth wieder "falsch" überschrieben.

Lösung war einfach im Width ein FClientWidth:=0; und fertig, aber neeeeeeeeeeee.

https://quality.embarcadero.com/browse/RSP-33368
.
https://quality.embarcadero.com/browse/RSP-29378
https://quality.embarcadero.com/browse/RSP-36016
...

Im Programm kann man sich da problemlos in seine FormKlasse oder einen Vorfahren die Setter überschreiben und es reparieren,
aber im FormDesigner kommt man nur per Hook dran. (bei uns sind deswegen zusammen mehrere Wochen an Arbeitszeit draufgegangen, für etwas, das Emba hätte mit zwei Zeilen Code lösen können)

Zitat:

Dafür ist nicht zwingend ein Hook notwendig

Das sieht bei Formvererbung anders aus, aber auch ohne schon.

Wenn du das dort, an dieser Stelle, änderst, dann wird/kann kann es passieren, dass OnCreate doppelt ausgeführt wird, im alten Delphi.
Im Constructor, da der den Wert aus DFM beachtet wird, dann schreibt Loaded es um und AfterConstruction sieht den neuen Wert und macht es nochmal. :duck:
War mir vor kurzem einmal aufgefallen, da im OnCreate eine TComponent erstellt wurde und es dann hieß "Name gibt es schon *peng*".

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1539954)

Wenn du das dort, an dieser Stelle, änderst, dann wird/kann kann es passieren, dass OnCreate doppelt ausgeführt wird, im alten Delphi.
Im Constructor, da der den Wert aus DFM beachtet wird, dann schreibt Loaded es um und AfterConstruction sieht den neuen Wert und macht es nochmal.

Von wie altem Delphi reden wir denn hier? Ich habe das konkret bei Delphi 5, 7 und 10 überprüft (also in der DFM steht dann OldCreateOrder = True): Das OldCreateOrder wird immer erst nach dem Loaded ausgewertet (würde sonst ja auch keinen Sinn ergeben, den Wert in die DFM zu schreiben).

Selbst wenn man den Constructer überschreibt, ist vor dem inherited noch keine DFM geladen und nach dem inherited das Loaded bereits ausgeführt. Damit is Loaded eine sichere Stelle den Wert passend zu setzen.

Übrigens ist das Verfahren keine echte (visuelle) Formvererbung, da ja alle Forms weiterhin von TForm abgeleitet bleiben und in der DFM steht auch object und nicht inherited. Man muss nur die Unit in die davor stehende uses-Anweisung setzen.

[himitsu]

Um es nochmals zu trennen
* einmal OldCreateOrder, bei uns zwischen XE und D11
* und andererseits LadeProbleme im D11, z.B. bei ClientWidth und Width, mit Zuweisung im Code (Create bzw. OnCreate) sowie Unterschiede zwischen DFMs bezüglich der FormVererbung
z.B. in VorfahrDFM ClientWidth und in NachfahrDFM mit Width, oder Width im Create oder OnCreate und ClientWidth in DFM.

Es gab immer wieder irgendwo ein paar Sonderfälle, wo es mit dem OldCreateOrder:=False; irgendwo nicht mehr ging.
In DFM mit False, in DFM mit True, nicht in DFM oder teilweise in DFM und dann auch noch unterschiedlich, ...

Wir haben hier aber auch eine wilde Mischung.
* im Delphi mit FormVererbung (mehrere DFM pro Form)
* über den Greatis FormDesigner die DFM zur Laufzeit aus der Datenbank
* manuell zur Laufzeit die DFM aus der Datenbank (TReader.ReadRootComponent)


Ich glaub ganz zu Beginn hatte Emba im DataModul das Ignore-OldCreateOrder vergessen und dann knallte es, wenn das noch in der DFM stand.
Da wir zur Laufzeit fehlerhafte Property ignorieren, ähnlich wie im FormDesigner der IDE (wobei wir ebenfalls den Fehler abgangen und ins Log schreiben, bzw. anzeigen, anstatt abrauchen zu lassen)
Dem TReader.OnError im Form.ReadState etwas zugewiesen und darin Handled=True.


Den letzten Fall, wo OnCreate doppelt ausgeführt wurde, hatte ich dann so abgefangen.
Da wir die Stelle nicht fanden, wo/warum hier OldCreate immernoch/wieder True war, wurde letztendlich einfach das erste OnCreate (hier im inherited) unterdrückt.

Delphi-Quellcode:

procedure TCimBaseForm.DoCreate;
begin
  { TODO -oUmstieg XE DX/D11 -cUmstieg XE DX/D11 : Dieses Handling kann entfernt werden, sobald kein XE mehr benutzt wird }
  // Delphi 11 löscht OldCreateOrder, weil es seit längerem nicht mehr benutzt wird
  // Delphi XE fügt im FormDesigner OldCreateOrder:=True; ein, wenn es das Property (noch) nicht findet. Es muß aber False sein/bleiben.
  {$IFDEF VER220 DelphiXE}
  // Wenn OldCreateOrder=True in DFM steht dann kommst es schon im Constructor hier vorbei, aber es darf erst im AfterConstrution hier ankommen.
  // Außer dem StackTrace hab ich aber nichts gefunden, was hier erkennen lässt, wer das aufruft.
  // Im AfterConstruction ist es aber definitiv False, da siehe TCimBaseForm.Create, somit kann es hier eigentlich nur noch vom Constructor kommen
  // und in diesem Fall wird OnCreate nicht ausgefürt, da es sonnst doppelt ausgeführt wird, also nochmal in AfterContruction, und es dann knallt.
  if OldCreateOrder then begin
    OldCreateOrder := False;
    Exit;
  end;
  {$ENDIF}
  try
    inherited;
  except
    Exception.InsertStackInfo(SecureFullName('TCimBaseForm') + '.DoCreate');
    // TCustomForm.DoCreate - TCustomForm.HandleCreateException -> Application.HandleException -> THauptForm.ApplicationEvents1Exception -> CimShowExceptionDialog
  end;
end;

Loaded ist aber auch nicht deterministisch.
Vor allem bei FormVererbung und/oder Kreuzreferenzen von Forms/Datenmodulen/Komponenten, wird das verzögert.
z.B. auf einer Form ein TDBEdit und eine TDataSource, aber das Edit vor der DataSource in der DFM, dann kann dem Edit.DataSource die DataSource noch nicht zugewiesen werden,
somit ist beim DBEdit.Loaded dieses Property noch nicht gesetzt, da es dann erst ganz am Ende zugewiesen wird und dann da nochmals dessen Loaded.

Das betrifft auch DatenModule und Frames, wo nach dem Laden dieser eventuell erst viel Später, also nach dem Laden aller zusammengehörenden Forms/Frames/Datenmodule
die fehlenden Referenzen aufgelöst werden und erst dann das Loaded ausgelöst wird. (z.B. GlobalFixupReferences)

[QuickAndDirty]

Ein text-suchen-und-erstzen nach OldCreateOrder in PAS und DFM dateien geht nicht?
Dann hat man halt ne D12 code base und gut , oder ?

[himitsu]

Delphi 12 ist hier nicht das Problem (des löscht es von alleine raus).
Dort gibt es inzwischen auch einen Code, welcher dieses Property beim DFM-Lesen ignoriert, da es dieses Property an der Formklasse nicht mehr gibt und es beim Laden sonst knallen würde.

Problem ist, wenn eine Form in D11/D12 bearbeitet und gespeichert wurde, dass es dann im alten Delphi Probleme damit gibt, wenn D11/D12 dieses Property gelöscht hat und das alte Delphi denkt diese DFM kommt aus einem ganz extrem uralten Delphi und es dieses Property "falsch" wieder einfügt (True statt False).

z.B. wenn man parallel mit zwei/mehr DelphiVersionen arbeitet, bzw. man seinen Code noch abwärtskompatibel zur alten Version halten muß,
weil eventuell der aktuelle ReleaseBranch und alte ReleaseBranches für Bugfixes noch mit dem alten Delphi arbeiten, während man in Master-/Bug-/FeatureBranches schon mit dem neuen Delphi rumspielt,
bzw. man alles noch auf alt lauffähig hält, falls es im neuen Delphi D11 weitere unzumutbare Probleme gibt und man notfalls wieder zurück zum XE will/muß.

[SearchBot]

Oki,

es läuft schon mal nicht schlecht. Ich habe jetzt eine saubere Trennung der Quelltexte vom Berlin und Athens gemacht - damit es keine Überschneidungen gibt, die seltsame Fehler auslösen.

Jetzt gerade habe ich das Problem - was im Berlin kein Problem war - mit einer Meldung:

Zitat:

[dcc32 Fehler] Unit1.pas(2501): E2251 Doppeldeutiger überladener Aufruf von 'ShowMessage'
Vcl.Dialogs.pas(6764): Verwandte Methode: procedure ShowMessage(const string);
Unit1.pas(1726): Verwandte Methode: procedure ShowMessage(const string; Char; TColor);

Mit dieser Funktion, die ich überall im Quelltext habe, schrieb ich mir eine neue Methode, die ein anders gestaltetes Fenster öffnet.
Ich hätte sie natürlich auch ShowMessage1 oder so nennen können, dann aber an hunderten Stellen es so ändern müssen - so ging es einfach am schnellsten.

Ich habe in der Unit die Deklaration so gemacht:

Delphi-Quellcode:

procedure ShowMessage(const Msg: string; icon:char='i'; color:TColor = clBlue); overload;

implementation

procedure ShowMessage(const Msg: string;icon:char='i'; color:TColor = clBlue); overload;
//Icon: 0:i 1:? 2:X 3:!
begin
  // hier mein modales Fenster konfigurieren und anzeigen
end;

Und obwohl das (für Berlin scheinbar) korrekt deklariert ist, meckert Athens herum. :pale:
Lasse ich "zur Deklaration springen" - öffnet es "Vcl.Dialogs" bei Showmessage.
Es ignoriert also meine lokale Deklaration.

Muss das über einen Compiler-Schalter, der das zulässt/vermeidet, bestimmt werden?

[Sherlock]

Schmeiß den Searchbot an und lass alles per globalem Suchen und Ersetzen zu einer vernünftig bezeichneten Methode umbenennen. ZB: SBShowMessage. Die paar vorkommenden "echten" ShowMessage Aufrufe korrigierst Du dann händisch zurück. Kompilerschalter haben immer den Hauch des vorübergehenden...

[himitsu]

Denk dir die/deine Default-Parameter weg
und was bleibt nun übrig?

Delphi-Quellcode:

//procedure ShowMessage(const Msg: string; icon:char='i'; color:TColor = clBlue);

Delphi-Quellcode:

procedure ShowMessage(const Msg: string);

also das Selbe, wie's Andere,

Delphi-Quellcode:

procedure ShowMessage(const Msg: string);

somit genau das, was dir die Fehlermeldung sagt.

[SearchBot]

Okay, dann mach ich das.

Aber schon interessant, daß das Berlin hierbei schlauer war als jetzt das Athens und es nicht als Fehler bemängelte, sondern richtig gemacht hatte.

[DeddyH]

Ich habe mir dafür vor einiger Zeit eine Unit geschrieben, die eine statische Klasse enthält, die wiederum Methoden hat, die intern die Windows-MessageBox aufrufen. Die Benutzung kann dann z.B. so aussehen:

Delphi-Quellcode:

TXXXDialog.ShowInfo('Pentagon erfolgreich gehackt');
if TXXXDialog.Confirm('Kreml auch gleich hacken?') then
  SiehZu();

Damit ist immer klar, was gemeint ist. Für FMX müsste das wohl erweitert werden, aber ich benutze seit Jahren nur noch VCL.

[Uwe Raabe]

Zitat:

Zitat von SearchBot (Beitrag 1540409)

Aber schon interessant, daß das Berlin hierbei schlauer war als jetzt das Athens und es nicht als Fehler bemängelte, sondern richtig gemacht hatte.

In Berlin war die ShowMessage nicht overload, während es in Athens jetzt zwei mit overload gekennzeichnete davon gibt. In Berlin hat deine Version einfach die Originalversion verdeckt, aber in Athens kommt es eben zu dieser Doppeldeutigkeit.

[SearchBot]

So, meine Funktion kann ich ja ändern.

Was mache ich aber, wenn es eine Funktion vom "festen" Quelltext ist?
Den hab ich nicht überladen.

Zitat:

[dcc32 Fehler] meineAPI.pas(537): E2251 Doppeldeutiger überladener Aufruf von 'AddPair'
System.JSON.pas(752): Verwandte Methode: function TJSONObject.AddPair(const string; const Boolean): TJSONObject;
System.JSON.pas(737): Verwandte Methode: function TJSONObject.AddPair(const string; const Extended): TJSONObject;
System.JSON.pas(707): Verwandte Methode: function TJSONObject.AddPair(const string; const string): TJSONObject;

Ursache ist wohl, daß ich dem 2. Parameter eine Variant-Variable übergebe, die mal eine Zahl oder ein String sein kann...

Delphi-Quellcode:

 
 if s<>'' then
  json.AddPair(prop,TJSONNumber.Create(s)) //s ist Typ string; prop ist shortstring
 else
  json.AddPair(prop,value); //<- hier meckert es! value ist Typ Variant, vielleicht numerisch

Wie erwähnt wusste Berlin, was zu tun ist - Athens beklagt das.
:?: Muss ich jetzt dem Compiler entgegen kommen und den 'varianten' Wert selbst vorbereiten?
:?: Oder gibt ein Schalter, der den Variant-Typ wie in Berlin selbst richtig einsetzt und die passende Funktion verwendet?

[himitsu]

Zitat:

wusste

Gab es dort eine Überladung mit Variant? (wo dann drin der interne Typ des Variant ausgewertet wird)

Wenn nicht, dann kann ich mir kaum vorstellen, dass Berlin es wusste und einfach blind in irgendeinen Typ gecastet hat ... was nicht unbedingt der richtige Typ sein muß.


Lösungen z.B. für Boolean:

Delphi-Quellcode:

json.AddPair(prop, Boolean(value)); 
json.AddPair(prop, VarToBool(value));

[SearchBot]

Zitat:

Zitat von himitsu (Beitrag 1540425)

Gab es dort eine Überladung mit Variant? (wo dann drin der interne Typ des Variant ausgewertet wird)

Lösungen z.B. für Boolean:

Delphi-Quellcode:

json.AddPair(prop, Boolean(value)); 
json.AddPair(prop, VarToBool(value));

Nein, ich habe da nichts überladen. Das mit dem VarTo.. sieht interessant aus, das werde ich versuchen (im Moment habe ich es auskommentiert, weil ich noch andere Probleme habe :stupid:).

Gerade ein anderes kniffliges Problem:
Ich habe SynEdit aus dem GetIt installiert.
Und weil im Git es dazu keine Issue gibt (und auch wenn ich ein neues Projekt damit starte, problemlos), wird das wahrscheinlich nur bei mir das Problem sein. In einem neuen Projekt funktioniert das SynEdit mit den selben Einstellungen :roll:

Wenn ich jetzt mein Projekt öffne, das ein SynEdit enthält, sagt mir die IDE, bevor noch irgendwas davon erscheint:

Zitat:

Listenindex außerhalb des gültigen Bereichs (0). TList<System.Integer> ist leer

Aha!?

Die Details erzählen mir..

Zitat:

[23308D4C]{SynEditDR290.bpl} System.Generics.Collections. + $24
[23319B83]{SynEditDR290.bpl} Syneditwordwrap.TSynWordWrapPlugin.RowCount + $1F
[233465D9]{SynEditDR290.bpl} Synedit.TCustomSynEdit.GetDisplayRowCount + $75
[23312CCF]{SynEditDR290.bpl} Syneditkbdhandler.Finalization + $A67
[23312D8A]{SynEditDR290.bpl} Syneditkbdhandler.Finalization + $B22
[23339F5D]{SynEditDR290.bpl} Synedit.TCustomSynEdit.UpdateScrollBars + $41
[23341971]{SynEditDR290.bpl} Synedit.TCustomSynEdit.SizeOrFontChanged + $D1
[2333A748]{SynEditDR290.bpl} Synedit.TCustomSynEdit.WMSize + $1C

Wenn ich die Komponente in ein neues Projekt kopiere, kommt es nicht zu diesem Fehler.

Beim Ausführen meines Programms knallt es mit der selben Meldung in der unit SynEditWordWrap hier (die // stammen vom Autor):

Delphi-Quellcode:

  // fLineOffsets[n] is the index of the first row of the [n+1]th line.
  // e.g. Starting row of first line (0) is 0. Starting row of second line (1)
  // is fLineOffsets[0]. Clear?

  TSynWordWrapPlugin = class(TInterfacedObject, ISynEditBufferPlugin)
  private
    fLineOffsets: TList<Integer>;

[...]
constructor TSynWordWrapPlugin.Create(aOwner: TCustomSynEdit);
begin
  inherited Create; // just to work as reminder in case I revert it to a TComponent...
  if aOwner = nil then
    raise Exception.Create( 'Owner of TSynWordWrapPlugin must be a TCustomSynEdit' );
  fEditor := aOwner;
  fLineCount := fEditor.Lines.Count;
  fLineOffsets := TList<Integer>.Create;
  fRowLengths := TList<Integer>.Create;
  Reset;
end;

function TSynWordWrapPlugin.RowCount: integer;
begin
  if fLineCount > 0 then
    Result := fLineOffsets[fLineCount - 1]; // <---- da: EArgumentOutOfRangeException

  Assert(fRowLengths.Count = Result);
end;

Ich kenne mich mit Generics nicht aus - fehlt da was bei der Initialisierung? Woran kann das sonst liegen und wie behebe ich das?

[himitsu]

Zitat:

Zitat von SearchBot (Beitrag 1540788)

Nein, ich habe da nichts überladen.

Nicht du, aber eventuell war es im alten Delphi anders implementiert?

Wollte vor mehreren Tagen schonmal fragen ... lag aber immernoch rum.
Hab ja nicht alle alten Delphi installiert, um da mal eben nachsehn zu können.
Sollte vielleicht doch endlich mal ein gewisses Projekt fertigstellen .... :gruebel:
https://www.delphipraxis.net/215806-...ml#post1540790

Zitat:

Zitat von SearchBot (Beitrag 1540788)

Das mit dem VarTo.. sieht interessant aus

Boolean(...) castet es in diesen Typ
und ist es NULL, dann knallt es, wiel es ja kein Boolean ist.

VarToBool macht der Gleiche, aber macht aus NULL ein False.

Ebenso z.B. VarToStr und VarToInt, wo aus NULL ein Leerstring '', bzw. 0 wird.

[SearchBot]

Wozu dient der Vcl.Forms.TForm.VisualManager ?

In der Online-Hilfe zu Delphi 12 ist dazu äußert informativ zu lesen :thumb::wall:

Zitat:

Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.

Es gibt in der Vcl auch keine Komponente auf der Palette dafür...

Warum frage ich?
Ich habe beim Einlesen meiner älteren Projekte irgendwie Darstellungs-Probleme (ich habe die Projekte nur mit den Dateien *.pas, *.dfm und die .dpr in einen neuen Ordner angelegt, ganz frisch also für Athens; keine *.res zunächst).
zB passen die Beschriftung der Checkboxen nicht mehr, die Buttons heben sich ganz hässlich nur farblich (dunkelgrau) vom Rest ab, also kein Rahmen herum.

Dann habe ich entdeckt, daß es die neuerdings Eigenschaft "StyleName" gibt und setze sie im Formular auf "Windows" - schon besser.
Starte ich dann das Programm, habe ich aber die blau glänzende Ansicht von Vista mit dem dicken Rahmen außen herum - und die Aufschrift der Titelleiste fehlt, bis ich die Fenstergröße ändere.

Warum kann das Programm nicht so ausgeführt werden, wie ich es im Designer der IDE sehe??
Was hat die IDE für ein Style?

Bei Berlin hatte ich ja schon Styles einrichten können - aber die haben sich sehr nachteilig auf die Aufbau-Geschwindigkeit der Darstellung ausgewirkt. Trotz DoubleBuffer flackern... - daher habe ich das dann gelassen.

:roll: Und was mache ich denn jetzt schon wieder falsch?

[Uwe Raabe]

Zitat:

Zitat von SearchBot (Beitrag 1540950)

Wozu dient der Vcl.Forms.TForm.VisualManager ?

Hat was mit der neuen MDI-Implementierung zu tun: Das Interface IFormVisualManager und die Eigenschaft VisualManager der Klasse TCustomForm

Wegen der Darstellungsprobleme müsstest du vielleicht etwas konkreter werden. Was du in der IDE siehst, hängt stark von den aktuellem Einstellungen unter Tools - Optionen - Benutzeroberfläche - Formular-Designer ab. Zur Laufzeit sind die Einstellungen unter Projekt - Optionen - Anwendung - Manifest und Erscheinungsbild relevant. Außerdem wären Screenshots von der fehlerhaften Darstellung hilfreich.

[himitsu]

Zitat:

Zitat von SearchBot (Beitrag 1540950)

zB passen die Beschriftung der Checkboxen nicht mehr, die Buttons heben sich ganz hässlich nur farblich (dunkelgrau) vom Rest ab, also kein Rahmen herum.

Im FormDesigner oder zur Laufzeit?

Die IDE ist seit 'ner Weile geskinnt (mit Design)
und leider sind die zu blöde den FormDesigner davon auszunehmen.

Im Designer kannst du bei deiner Form das Property StyleName auf "Windows" einstellen, dann sieht es dort so aus, wie später im Betrieb.
(persönlich würde ich es aber zur Laufzeit nicht so lassen)


Ich würde dir auch empfehlen nicht die neue automatisch generierte DPROJ zu nehmen, sondern ein neues VCL-Projekt zu erstellen und dessen DPROJ zu kopieren.
(es so nennen, wie dein Projekt oder den Projektnamen mit TextEditor drin an mehreren Stellen ändern)
Oder, da du ja garantiert eine Versionierung nutzt, einfach das neue Projekt drüberspeichern und dann alles, außer der DPROJ, reverten. :angle2:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1540954)

Die IDE ist seit 'ner Weile geskinnt (mit Design)
und leider sind die zu blöde den FormDesigner davon auszunehmen.

Das kann man aber doch abschalten: Tools - Optionen - Benutzeroberfläche - Formular-Designer - VCL-Stile aktivieren

Man sollte dann allerdings auch die IDE mit 96 DPI laufen lassen (falls das relevant ist), denn die fehlerhafte Darstellung eines runter-skalierten Forms ohne VCL-Style ist einfach nur grauenhaft.

[himitsu]

Was mich noch mehr nervt, dass Buttons und Edits alle ringsum je ein Pixel kleiner sind, im ungeskinnten Modus ... versucht da mal mehrere kleine Knöpfe/Edits/... ordentlich zu designen.

[SearchBot]

Zitat:

Zitat von Uwe Raabe (Beitrag 1540953)

Zitat:

Zitat von SearchBot (Beitrag 1540950)

Wozu dient der Vcl.Forms.TForm.VisualManager ?

Hat was mit der neuen MDI-Implementierung zu tun: Das Interface IFormVisualManager und die Eigenschaft VisualManager der Klasse TCustomForm

Wegen der Darstellungsprobleme müsstest du vielleicht etwas konkreter werden. Was du in der IDE siehst, hängt stark von den aktuellem Einstellungen unter Tools - Optionen - Benutzeroberfläche - Formular-Designer ab. Zur Laufzeit sind die Einstellungen unter Projekt - Optionen - Anwendung - Manifest und Erscheinungsbild relevant. Außerdem wären Screenshots von der fehlerhaften Darstellung hilfreich.

Das mit der Checkbox hab ich dann einfach mit der Fontgröße korrigiert.
Screenshot im Anhang, da stimmt was mit dem Image auf einem TButton nicht, weiß nicht, wie ich das fixen kann.

Wenn ich den Button anklicke, verändert er beim Loslassen sein Style auch kurz zur "windows-Style"-Variante, wird also Eckig mit deutlichen Kanten. Buttons ohne Image zeigen das auch, aber nur ganz kurz. Mit Image deutlich langsamer.

Ich habe auch überlegt, ob es ein Problem mit dem (in deinem Link beschriebenen) neuen DoubleBuffering gibt und den DoubleBufferedMode von dbmDefault auf dbmRequested geändert - aber das zeigt das Image trotzdem nicht an.

[SearchBot]

Zitat:

Zitat von SearchBot (Beitrag 1540788)

Wenn ich jetzt mein Projekt öffne, das ein SynEdit enthält, sagt mir die IDE, bevor noch irgendwas davon erscheint:

Zitat:

Listenindex außerhalb des gültigen Bereichs (0). TList<System.Integer> ist leer

Beim Ausführen meines Programms knallt es mit der selben Meldung in der unit SynEditWordWrap hier...:

Delphi-Quellcode:

function TSynWordWrapPlugin.RowCount: integer;
begin
  if fLineCount > 0 then
    Result := fLineOffsets[fLineCount - 1]; // <--- Exception

  Assert(fRowLengths.Count = Result);
end;

... wie behebe ich das?

Das habe ich soeben selbst gelöst: :cheer:

Delphi-Quellcode:

function TSynWordWrapPlugin.RowCount: integer;
begin
  if (fLineOffsets.Count > 0) // <-- richtig | falsch --> (fLineCount > 0)
    Result := fLineOffsets[fLineCount - 1]; // <---- da: EArgumentOutOfRangeException

  Assert(fRowLengths.Count = Result);
end;

[himitsu]

Und dann noch, dass hier jemand grob fahrlässig die Warnung des Compilers ignoriert.

Result nicht initialisiert

[SearchBot]

Zitat:

Zitat von himitsu (Beitrag 1541426)

Result nicht initialisiert

Ja, das ist wohl mir beim Abschreiben passiert :oops: - es steht da im Original noch

Code:

else result:=0;

[SearchBot]

Hi, noch was neues in Athens, was in Berlin noch schön war:

Die Komponente LabeledEdit.
Sie besitzt ja das Editfeld und ein Label darüber (oder wo es eben positioniert wird).

Das Label konnte ich bisher im ObjectInspektor direkt bearbeiten.
In Athens steht da bei der Eigenschaft "EditLabel" nur noch LabeledEdit1.Sublabel - aber kein Unterbereich mit Eigenschaften des Labels.
:pale: Bug?

Wie komme ich jetzt an die Eigenschaften des Labels wieder dran?

Edit: Aah, habs selbst gefunden:
In Eigenschaften des Objektinspektors gibts bei Referenzen eine Checkbox "Inline erweitern", dann klappt es wie gewohnt.
Da frage ich mich, warum man das abwählen kann und so auf Komfort verzichten will?!

[himitsu]

Vielleicht um Doppeltes zu entfernen.

z.B. DataSet und nochmal in DataSource.DataSet


Aber wenn, dann sollte man bei so Dingen, die nicht doppelt sind, angeben können, dass es immer inline erweitert werden MUß, egal was dieses Setting sagt. Und Emba sollte das dann bei eigenen Komponenten auch gleich anwenden.

[Uwe Raabe]

Die Option hat schon einen Einfluss, wenn die verlinkte Komponente auch direkt im OI editierbar ist. Bei dem Sublabel ist das allerdings nicht der Fall.

Ich kann mich aber nicht erinnern, dass das irgendwann mal deaktiviert war. Es kann aber sein, dass das einfach nur aus Kompatibilitätsgründen noch da ist.