Gute Neuigkeit! DEC 6.2 soeben released!

[TurboMagic]

Zitat von Andreas13:

Ich habe nur die Compiler-Direktive ausprobiert: Sie funktioniert.
Gruß, Andreas

Naja, die funktioniert bestimmt, hält aber die IDE nicht davon ab, diese Unit immer wieder
hinzuzufügen, wenn sie nicht im Uses steht.

[TurboMagic]

Zitat von Michael II:

"Besser" wäre: GetShortClassNameFromName anpassen. Diese Funktion liefert momentan für bereits gekürzte SHA3-Namen statt SHA3_<nnn> das Resultat <nnn> zurück.

Delphi-Quellcode:

class function TDECObject.GetShortClassNameFromName(const ClassName: string): string;
var
  i: Integer;
begin
  Result := ClassName;
  if pos( 'SHA3_', ClassName ) = 1 then exit;

  i := Pos('_', Result);
  if i > 0 then
    Delete(Result, 1, i);
end;

Also das möchte ich lieber nicht umsetzen. Warum?

1. Spezifisch für SHA3. Gibt's später weitere solche Fälle muss man immer dran denken die hier auch aufzunehmen
2. Die Methode soll doch einen kurzen Klassennamen von einem vollständigen liefern. Also soll man diese per Design ja mit einem vollständigen und nicht mit einem bereits gekürzten Namen füttern! Ich habe ja auch das Hash_FMX Demo Programm entsprechend angepasst und das funktioniert nach meiner Anpassung ja auch für SHA3_XXX.

Grüße
TurboMagic

[Andreas13]

Wie wäre es, wenn Du im aktuellen Projektverzeichnis eine leere Unit namens FMX.Grid.Style.pas ablegen würdest, um die DIE auszutricksen?
Gruß, Andreas

[TurboMagic]

Zitat von Andreas13:

Wie wäre es, wenn Du im aktuellen Projektverzeichnis eine leere Unit namens FMX.Grid.Style.pas ablegen würdest, um die DIE auszutricksen?
Gruß, Andreas

Daran habe ich auch schon kurz gedacht, da ich aber nicht weiß, wofür diese Unit in 10.4.x benutzt wird würde
ich das dann ja auch austricksen...
Könnte ich evtl. nacher mal testen was dann passiert.

[TurboMagic]

Wer will kann die aktuellen Arbeiten zur Beseitigung dieser Bugs gerne Testen.
Über Rückmeldungen würde ich mich freuen.

Diese sind in diesem Branch:

https://github.com/MHumm/DelphiEncry...elease_for_6.2

- deplyoproj für Hash_FMX gefixt
- HashBenchmark FMX: StringColumn2.HorzAlign := TTextAlign.Trailing; Problem begrenzt.
Sollte jetzt keinen Fehler mehr beim Laden der FMX Datei werden, nur das mit dem
automatischen Hinzufügen der FMX.Grid.Style Unit hab' ich noch nicht im Griff.
Ich weiß auch noch nicht, was ich von der Idee halten soll, eine leere Unit
gleichen Namens im Projekt anzulegen. Was macht 10.4.x drauß, die IDE wird das
ja nicht umsonst hinzufügen...

Grüße
TurboMagic

[EdAdvokat]

Ich habe nun die ersten Testversuche mit der gepachten Version 6.2.1 durchgeführt und folgende Ergebnisse erzielt:

1. Mit Delphi 10.2 und 10.3 habe ich beim Kompilieren mit F9 immer wieder die Fehlermeldung E1026 mit dem Hinweis, dass MainForm.dfm in einem FMX Programm fehlen würde.
Nachdem ich das Programm mit "Erstellen" und danach mit F9 kompiliere erhalte ich keine Fehlermeldungen bei Cipher_FMX, Hash_FMX und Benchmark_FMX.

2. Test mit Delphi 10 Seattle sieht da anders aus: Cipher_FMX läßt sich nicht kompilieren, da FMX.Grid.Style nicht gefunden wird.
Hash_FMX gibt eine Fehlermeldung für Zeile 156 - 165 aus. FormMain.ShowErrorMessage dort sei IFMXDialogServiceAsync nicht bekannt
Vermutlich ist Seattle für das Programm in Fragen FMX zu alt oder?

Benchmark_FMX wirft beim Aufruf den bekannten Fehler sg_Results.Options; Nach ignorieren und Kompilierungsversuch Fehler: FMX.Grid.Style nicht gefunden.
Also Seattle scheint wohl für das DEC-Projekt nicht geeignet zu sein.

Soweit meine ersten Testversuche.
Interessant für mich und auch neu ist der Fehler E1026. Was könnte das denn sein? Das hatte ich bisher nur in den DEC-Projekten.
Komischerweise ist alles i.o wenn ich das Programm mit Erzeugen und dann F9 starte. Hat da jemand eine Erklärung?

[Michael II]

Zitat von TurboMagic:

Also das möchte ich lieber nicht umsetzen. Warum?

1. Spezifisch für SHA3. Gibt's später weitere solche Fälle muss man immer dran denken die hier auch aufzunehmen
2. Die Methode soll doch einen kurzen Klassennamen von einem vollständigen liefern. Also soll man diese per Design ja mit einem vollständigen und nicht mit einem bereits gekürzten Namen füttern! Ich habe ja auch das Hash_FMX Demo Programm entsprechend angepasst und das funktioniert nach meiner Anpassung ja auch für SHA3_XXX.

Grüße
TurboMagic

Hallo TM,

Dein DEC - Dein Entscheid.

Mir ist klar, was die Funktion tun sollte [vollständiger Klassenname -> Kurzname]. (Mit der Änderung hätte sie auch Kurzname -> Kurzname funktioniert.)

Wenn du sicher bist, dass GetShortClassNameFromName() ab DEC 6.2+ nie mehr mit Kurznamen als Argument aufgerufen wird, dann OK. Wenn du nicht sicher bist, dann würde ich die Funktion umschreiben und eine "Exception raisen", wenn ein unbekannter Klassenname als Argument übergeben wird. Dann würde die Funktion auch sicher das tun, was du von ihr willst.

Gruss
Michael

[TurboMagic]

Zitat von EdAdvokat:

2. Test mit Delphi 10 Seattle sieht da anders aus: Cipher_FMX läßt sich nicht kompilieren, da FMX.Grid.Style nicht gefunden wird.
Hash_FMX gibt eine Fehlermeldung für Zeile 156 - 165 aus. FormMain.ShowErrorMessage dort sei IFMXDialogServiceAsync nicht bekannt
Vermutlich ist Seattle für das Programm in Fragen FMX zu alt oder?

Benchmark_FMX wirft beim Aufruf den bekannten Fehler sg_Results.Options; Nach ignorieren und Kompilierungsversuch Fehler: FMX.Grid.Style nicht gefunden.
Also Seattle scheint wohl für das DEC-Projekt nicht geeignet zu sein.

Hab noch nicht wirklich Zeit dafür gefunden, aber am Benchmark_FMX eine Änderung vorgenommen.
Kannst du die mal testen?

Die FMX.Grid.Style sollte dadurch jetzt erst ab 10.4 eingebunden werden:

Delphi-Quellcode:

  {$IF RTLVersion < 34}
  {$ELSE}
  FMX.Grid.Style,
  {$ENDIF}

[EdAdvokat]

Hallo Markus,
Habe also mit Delphi Seattle das Programm Benchmark_FMX nochmals getestet:
beim Laden der dpr-Datei erneut der Hinweis sg_Results.Options:ungültiger Eigenschaftswert (wie bereits von zuvor bekannt) dann ignorieren und Programm kompiliert mit Fehlermeldung:
Zeile 229: auf privete-Symbol TTime.Span.tostring kann nicht zugegriffen werden.
Habe daraufhin geprüft ob tostring überhaupt mit dem Aufruf möglich ist - nein, also tostring auskommentiert und ; hinter Elapsed gesetzt.
Danach läßt sich das Programm kompilieren und zeigt auch Zeiten an. Ob die wirklich so richtig sind kann ich nicht genau bestimmen. Jedenfalls läuft das Programm ohne tostring.
Da tostring ja nur die Werte in strings umwandeln soll und die Zeit tatsächlich auch angezeigt wird, dürfte ja inhaltlich an der Zeitbestimmung nichts verändert worden sein.

Hier nochmals dieser Abschnitt mit der von mir vorgenommenen Auskommentierung:

procedure TFormMain.RunBenchmark(ClassName: string; RowIndex: Integer);
var
Hash : TDECHash;
HashResult : TBytes;
i : Integer;
begin
Hash := TDECHash.ClassByName(ClassName).Create;

try
FStopwatch.Reset;
FStopwatch.Start;

for i := 0 to cIterations - 1 do
begin
HashResult := Hash.CalcBytes(FBenchmarkBuffer);
end;

FStopwatch.Stop;

sg_Results.Cells[1, RowIndex] :=
Format('%0:f', [cIterations / (FStopwatch.ElapsedMilliseconds/1000)]);
sg_Results.Cells[2, RowIndex] := FStopwatch.Elapsed; //.ToString;
finally
Hash.Free;
end;
end;

Soweit Benchmark_FMX-test mit Delphi Seattle. Die Problematik FMX.Grid.Style hat wohl funktioniert und sollte ggf auch auf andere Dateien angewendet werden, falls erforderlich.

[EdAdvokat]

Entschuldigung, habe den "Helm" leider nicht exakt aufgesetzt:

Delphi-Quellcode:

procedure TFormMain.RunBenchmark(ClassName: string; RowIndex: Integer);
var
  Hash       : TDECHash;
  HashResult : TBytes;
  i          : Integer;
begin
  Hash := TDECHash.ClassByName(ClassName).Create;

  try
    FStopwatch.Reset;
    FStopwatch.Start;

    for i := 0 to cIterations - 1 do
    begin
      HashResult := Hash.CalcBytes(FBenchmarkBuffer);
    end;

    FStopwatch.Stop;

    sg_Results.Cells[1, RowIndex] :=
      Format('%0:f', [cIterations / (FStopwatch.ElapsedMilliseconds/1000)]);
    sg_Results.Cells[2, RowIndex] := FStopwatch.Elapsed;  //.ToString;
  finally
    Hash.Free;
  end;
end;