Gute Neuigkeit! DEC 6.2 soeben released!

[TurboMagic]

Hallo,

gerade eben wurde eine neue Version der DEC (Delphi Encryption Compendium) veröffentlicht:

https://github.com/MHumm/DelphiEncry...eases/tag/V6.2

Was ist alles neu?

• Regressionen beseigigt, auch welche die Compilieren mit älteren Compilern verhindern (Support für ältere COmpiler kann aber in Zukunft eingeschränkt werden!)
• Fehler in den Verschlüsselungsalgorithmen SCOP und SHARK korrigiert
• Die Unit Tests für die Hash Algorithmen, soweit noch fehlend und möglich, um originale Testvektoren ergänzt
• Den SHA3 Hash Algorithmus für 224, 256, 384 und 512 Bit hinzugefügt, inklusive Unterstützung für Nachrichtenlängen die nicht auf ganze Bytes ausgerichtet sind und Nutzung von Eric Grange's optimierter Assembler Umsetzung auf Win32/Win64
• Neues Demo Programm: Hash Benchmark FMX

Viel Spaß damit. Die GetIt Lite Version wird in den nächsten Tagen folgen.

Grüße
TurboMagic

[Andreas13]

Vielen Dank, TurboMagic! :thumb: :angel:
Gruß, Andreas

[TurboMagic]

Für diejenigen, die das gerne per GetIt in der IDE installieren (dann aber halt nur eine Lite Version ohne Verschlüsselungen bekommen):
die nötige Lite Version wurde eben für GetIt Publikation eingereicht. Sollte also hoffentlich zügig als V6.2 Lite verfügbar sein.

[EdAdvokat]

ich habe die neuen SHA3-Hash-Funktionen sowohl in ein VCL als auch in das FMX-Projekt eingebunden und es kompiliert ohne Fehlermeldung. Rufe ich jedoch diese 3 neuen Hash-Funktionen
auf, um damit einen Hash zu erstellen, erhalte ich folgende Meldung
Project1
---------------------------
Class SHA3_224 is not registered.
---------------------------
OK
---------------------------
was bedeutet das? Wie sollte die class SHA3_224 und die anderen SHA3-class registerit werden?
Ich habe das Beispielprojekt FMX-Hash mit allen DEC-Hash-Funktionen auch auf VCL umgeschrieben. Bei beiden Projekten das gleiche Problem, jedoch nur bei den neuen SHA3-Hash.

[EdAdvokat]

Hallo Markus, schau doch mal nach Hash_FMX und auch HashBenschmark_FMX in den Demos. Da gibt es Fehlermeldungen und die Programme lassen sich nicht kompilieren. Es wird ein Problem mit der Datei Hash_FMX.deployproj Zeile 7 Pos 2.... gemeldet.
05:35 Uhr Erstellungszeit war wohl etwas spät oder zu früh.
Ich hatte Hash_FMX und Hash_VCL mit meinen Projekten aus der Vorversion und mit den jetzt neuen units getestet und das Problem mit der Registrierung (s.o.) festgestellt.
Nun habe ich Deine neuen Demos getestet und das o.g. festgestellt.

[TurboMagic]

Guten Morgen,

ich schaue mir die Probleme später an, kann mir die aber noch nicht wirklich erklären:

1. Wie benutzt du in deinen Programmen die SHA3 Umsetzung?

2. Ich hatte während meiner abschließenden Tests von 6.2 auch einen "nicht registriert"
Fehler in der FMX Demo, den habe ich aber durch eine Änderung der FMX Demo gelöst.
Dort kam es zu Problemen mit den SHA3 Klassen weil diese 2x _ statt nur 1x _ enthalten
und die Suche nach der richtigen Klasse in der Registrierungsliste nicht mit dem vollen
Klassennamen durchgeführt worden war.

3. Das mit dem Deployprojekt kann ich mir nicht erklären. Um die angegebene Uhrzeit
schlafe ich normalerweise. Die einzig mögliche Erklärung für mich wäre, dass die Uhrzeit
der genutzten VM nicht mit dem Host synchronisiert ist, das hatte ich neulich mal in
einer VM, da war das nicht eingeschaltet. Ich weiß aber nicht mehr in welcher VM das war.

Grüße
TurboMagic

[TurboMagic]

Hallo,

ich habe eben versucht das Problem mit dem Hash_FMX Deomo Programm nachzustellen,
jedoch erfolglos. Hier meine Schritte in D10.4.2:

1. Projekt aktivieren
2. Ausführen mittels F9
3. Hash Funktion SHA3_224 auswählen
4. Input Format auf "Copy" stellen
5. Output format auf "HEX" stellen
6. "Live calculation" ankreuzen
7. Test in das Eingabefeld eingeben

Funktioniert wunderbar, ohne Fehlermeldung und zeigt nach jedem eingetippten Buchstaben
einen total anderen Hash an.

=> ich müsste mal bitte wissen, was du genau gemacht hast. Das würde die Fehlersuche
glaube ich stark vereinfachen.

[TurboMagic]

Hier übrigens noch, was bei mir in der Hash_FMX.deployproj Datei drin steht,
beginnend ab Zeile 6:

<PropertyGroup>
<DeviceId Condition="'$(Platform)'=='Android'">CB512EA59X</DeviceId>
<DeviceId Condition="'$(Platform)'=='Android64'">CB512EA59X</DeviceId>
</PropertyGroup>

Ich habe mir die auch mit einem Hex-Editor angeschaut und auch da sieht's unverdächtig aus.

[Michael II]

Wenn ich ...\DEC\Demos\Hash_FMX\Hash_FMX.dproj lade, dann wird auch bei mir angezeigt:
Fehler
Projekt ...\DEC\Demos\Hash_FMX\Hash_FMX.dproj kann nicht geladen werden
Die importierte Projektdatei konnte nicht geladen werden. Ein Name darf nicht mit dem Zeichen '<', hexadezimaler Wert 0x3C, beginnen. Zeile 7, Position 2. ...\DEC\Demos\Hash_FMX\Hash_FMX.deployproj
Korrigiert: Demos\Hash_FMX\Hash_FMX.deployproj scheint nicht mehr OK formatiert zu sein, in diesem File hat's zu viele <<<< und >>>> drin.

Zur zweiten Meldung: HashBenschmark_FMX läuft bei mir ohne Probleme durch.
Hast du eventuell DEC 6.2 woanders installiert und die neuen Pfade via ...\DEC\Install nicht gesetzt?

[TurboMagic]

Alles seltsam.
Evtl. hat er auch die Pfade Setzen ANwendung ausgeführt, danach aber vergessen die IDE neu zu starten.

Und das mit der deployproj Datei finde ich auch seltsam. Was könnte man da tun um das zu korrigieren?

[EdAdvokat]

Nachfolgende Aktionen mit Delphi 10 Seatle Prof getestet:
1. Beim Kompilieren von Hash_FMX aus den Demos von 6.2 erhalte ich nachfolgenden Fehler:
The imported project file could not be loaded. Ein Name darf nicht mit dem Zeichen '<', hexadezimaler Wert 0x3C, beginnen. Zeile 7, Position 2. C:\Users\nowe4\Documents\delphiPrg\A_Crypto\a_DEC\ DEC62\Demos\Hash_FMX\Hash_FMX.deployproj
[Fataler Fehler] The imported project file could not be loaded. Ein Name darf nicht mit dem Zeichen '<', hexadezimaler Wert 0x3C, beginnen. Zeile 7, Position 2. C:\Users\nowe4\Documents\delphiPrg\A_Crypto\a_DEC\ DEC62\Demos\Hash_FMX\Hash_FMX.deployproj

2. Beim Aufruf von Benchmark erhalte ich folgenden Fehler:
Fehler beim Lesen des Formulars 'FormMain'
Fehler beim Lesen von sg_Results.Options: Ungültiger Eigenschaftswert. Den Fehler ignorieren und fortsetzen? Hinweis: Durch Ignorieren des Fehlers könnten Komponenten gelöscht werden oder Eigenschaftswerte verloren gehen.
Ignorieren gewählt:
gleiche Fehlermeldung nur ...beim Lesen von StringColumn2.HorzAlign: Eigenschaft HorzAlign existiert nicht....
ignorieren gewählt:
Form läßt sich laden; beim Kompilieren Fehler [dcc32 Fataler Fehler] MainForm.pas(24): F2613 Unit 'FMX.Grid.Style' nicht gefunden.

3. Hash_VCL von mir umgeschrieben aus der alten Demo von Hash_FMX mit den neuen units von 6.2 mit Delphi Seatle getestet (auch mit Delphi 10.2 gestern mit gleichem Ergebnis):
Programm liegt anliegend bei. Ergebnis: Kompilierung möglich doch beim Einstellen der SHA3 Hashtypen kommt die Meldung der fehlenden Registierung der class (siehe Post #4)

Das mit der Zeit war ein Spass ohne programmtechnischen Hintergrund !

Ich teste das ganze nochmals mit Delphi 10.2 und melde mich dann nochmals.

[EdAdvokat]

Hier das vormals angekündigte Programm Hash_VCL

[Michael II]

Das Problem tritt in deiner Funktion
function TDECClassList.ClassByName(const Name: string): TDECClass;
auf.

Du rufst dort aus DECBaseClass TDECClass.GetShortClassNameFromName(Name) auf. Weil die SHA3 Hashes Namen mit dem Zeichen "_" (SHA3_224 etc.) haben, liefert GetShortClassNameFromName(Name) nicht den erwarteten Wert zurück. => Dein FindNameShort wird immer FALSE und Result bleibt NIL. => Du löst bei Result=NIL in deiner Funktion die falsche Exception EDECClassNotRegisteredException.CreateResFmt aus.

SHA3_xxx sind registriert und funktionieren.

Falls ich deinen Code korrekt lese: Da du im FormCreate über InitHashCombo; und InitFormatCombos; die Hash- und Formatwerte initialisierst, reicht in deiner Funktion als Workaround generell (oder mind. für SHA3_..) FindNameShort := TRUE.

[EdAdvokat]

Test mit Delphi 10.2 und 10.3 gleiche Ergebnisse:
Hash_FMX nach Kompilieren Fehler:
The imported project file could not be loaded. Ein Name darf nicht mit dem Zeichen '<', hexadezimaler Wert 0x3C, beginnen. Zeile 7, Position 2. C:\Users\nowe4\Documents\DelphiPrg\DEC62\Demos\Has h_FMX\Hash_FMX.deployproj

HashBenchmark_FMX Fehlermeldung stringColumn2.... wie oben dann Inorieren und Programm läßt sich kompilieren.
Nach weiteren Aufrufen der .dpr kommt diese Fehlermeldung nicht mehr und das Programm läßt sich kompilieren.

Dann tauchte bei mir bei der Kompilierung 32bit HashBenchmark_FMX ein völlig eigenartiger Fehler E1026 auf, mit dem ich überhaupt nichts anfangen kann.
Es wird in einem FMX-Programm die fehlende MainForm.dfm angemahnt.
Was mag das wohl sein, denn in dem gesamten FMX-Programm ist an keiner Stelle ein Hinweis auf MainForm.dfm zu finden.
Das gibt mir ein völliges Rätsel auf.
[dcc32 Fehler] E1026 Datei nicht gefunden: 'MainForm.dfm' beim Aufruf von HashBenchmark_FMX !!!

HashBenchmark_FMS 64bit kompiliert - alles i.o eigenartig.

Programm Cipher_FMX läßt sich kompilieren in 10.2 aber Fehlermeldung:
---------------------------
Anwendungsfehler
---------------------------
Exception EReadError in Modul Cipher_FMX.exe bei 000BC8A4.

Fehler beim Lesen von ComboBoxCipherAlgorithm.OnChange: Ungültiger Eigenschaftswert.

---------------------------
OK
---------------------------

Ich habe das in der VM mit 10.2 und 10.3 getestet, nachdem ich die DEC 6.2 dort jeweils neu und erstmals installiert habe.
Einiges gibt mir Rätsel auf.

[EdAdvokat]

Hallo Michael II Das schaue ich mir in Ruhe an und gebe Bescheid.

[Michael II]

Hallo EdAdvokat

bei deinem zweiten gemeldeten Problem:
In Hash_FMX.deployproj hat's tatsächlich etwas viele <<<< und >>>> drin.
u.a. aber nicht nur wie von Delphi gemeldet an Postion Zeile 7 Spalte 2.

Ein Fall für TM ;-).

Gruss
M

[EdAdvokat]

@Michael II mit Deinem Post #13 beziehst Du dich vermutlich auf die DEC-unit DECBaseClass.pas und regst an, dort eine Änderung vorzunehmen.
Dies ist sicher dann an TurboMagic gerichtet.

[Michael II]

Zitat:

Zitat von EdAdvokat (Beitrag 1492009)

@Michael II mit Deinem Post #13 beziehst Du dich vermutlich auf die DEC-unit DECBaseClass.pas und regst an, dort eine Änderung vorzunehmen.
Dies ist sicher dann an TurboMagic gerichtet.

Hallo EdAdvokat,

ja genau. Ich meinte, ich wäre da in deinem Teil des Codes unterwegs.

Falls du deine App kurzfristig benötigst, dann reicht für dich der erwähnte WorkAround. Dann zeigt deine App auch die SHA3 Werte korrekt an.

"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;

Schön hast du das gefunden.

Gruss
M

[TurboMagic]

Zitat:

Zitat von EdAdvokat (Beitrag 1491971)

Hallo Markus, schau doch mal nach Hash_FMX und auch HashBenschmark_FMX in den Demos. Da gibt es Fehlermeldungen und die Programme lassen sich nicht kompilieren. Es wird ein Problem mit der Datei Hash_FMX.deployproj Zeile 7 Pos 2.... gemeldet.
05:35 Uhr Erstellungszeit war wohl etwas spät oder zu früh.
Ich hatte Hash_FMX und Hash_VCL mit meinen Projekten aus der Vorversion und mit den jetzt neuen units getestet und das Problem mit der Registrierung (s.o.) festgestellt.
Nun habe ich Deine neuen Demos getestet und das o.g. festgestellt.

Ok, ich versuche mich mal mit der Ursachenforschung, so wie ich das verstanden habe gibt's 3 Probleme:

1. .deployproj Datei

2. Klassenregistrierungsmechanismus, hat wohl doch noch ein Problem mit dem zusätzlichen _ bei den SHA3 Umsetzungen

3. FMX Formular enthält eine Eigenschaft die es früher noch nicht gab.

Habe ich das richtig erfasst?

Zu 1.: das kann ich gerade nicht nachvollziehen. Ich habe eben geschaut, das in der Hash_FMX Demo im Masterbranch auf Github
in dieser Datei drin steht. Und dort sieht diese korrekt aus. Letzte Änderung der Datei vor 3 Tagen, also am Sonntag als ich
released habe.

Hier kann man die Datei anschauen und sehen, dass da keine <<<<<< drin sind. Das wären wohl Marker von Git.
https://github.com/MHumm/DelphiEncry...FMX.deployproj

2. und 3. schaue ich gleich an.

[TurboMagic]

Hallo,

das HorzAlign beim FMX StringGrid scheint in Sydney neu rein gekommen zu sein,
zumindest gibt's da im Dokwiki eine komplette Stub-Docwiki Seite für, die es für
Rio in der Form noch nicht gibt.

Was kann ich in so einem Fall überhaupt tun?
Ja, ich könnte die Zeile aus der .FMX Datei nehmen und mittels $IF Compilerversion > X
im Code der Demo für die neueren Versionen setzen. Wäre das ein geeigneter Ansatz?

Grüße

TurboMagic

[TurboMagic]

Hallo,

ok, das mit der deployproj hab' ich jetzt kapiert.
Keine Ahnung wie das zustande kam, aber das kann ich lösen.

Weitere Arbeiten an diesen Problemen aber wohl erst morgen.

Grüße
TurboMagic

[EdAdvokat]

Hallo Markus,
zu 1. nicht Cipher.fmx sondern bei Hash_FMX.deployproj war gemeint. Schau doch mal in diese Datei, die Du im ersten Post verlinkt hast. Dort sind div. <<< >>> usw.
enthalten, die da sicher nicht hingehören.
zu 2. Zum Klassenregisterungsmechanismus hat meiner Meinung nach Michael II eine akzeptable Lösung gefunden, die man einpflegen könnte.
zu 3. FMX Formular enthält vermutlich Eigenschaften die es vor 10.4 nicht gab. Das vermute ich auch.
Nachdem ich mehrfach mit dem HashBenchmark_FMX heraumgedocktert habe, gab es lediglich den Hinweis auf die nicht enthaltene Eigenschaft, aber HashBenchmark_FMX ließ
sich kompilieren. Evtl. diese Eigenschaft herausnehmen, denn so geht es auch.
Also in Deinem Post #20 schlägst Du eine doch akzeptable Lösung vor. Es geht doch in der Sache um den Benchmark und nicht um die "Schönheit und Vollkommenheit der
Bits und Bytes".

[EdAdvokat]

Hallo anbei der Link zur bewußten Datei mit den <<<>>> usw., die nochmals überprüft werden sollte
https://github.com/MHumm/DelphiEncry...FMX.deployproj

[TurboMagic]

Hallo,

habe mit dem Bugfix Arbeiten begonnen.
Sind in einem neuen 6.2.1 Branch. Deployproj ist schon gefixt, Rest kommt auch noch der Reihe nach.

Grüße
TurboMagic

[TurboMagic]

Problem:

Ich versucht das mit dieser FMX Eigenschaft in HashBenchmark zu fixen und gleichzeitig diese
in früheren Versionen nicht vorhandene FMX.Grid.Style Unit nur ab Sydney in den Uses auftauchen
zu lassen. Nur klappt mindestens letzteres nicht, da bei jedem Speichern oder Compilieren des
Projektes diese Unit von der IDE wieder hinzugefügt wird. :-(

Was kann ich da tun?
Das hier versteht die IDE leider nicht:

Delphi-Quellcode:

  {$IF CompilerVersion >= 34.0}
  FMX.Grid.Style,
  {$ENDIF}

[NormanNG]

eine Möglichkeit:

wenn die fraglichen Komponenten manuell im OnCreate o.ä. erzeugt werden, steht nichts falsches in der DFM....

[Andreas13]

Zitat:

Zitat von TurboMagic (Beitrag 1492036)

Was kann ich da tun?
Das hier versteht die IDE leider nicht:

Delphi-Quellcode:

  {$IF CompilerVersion >= 34.0}
  FMX.Grid.Style,
  {$ENDIF}

Hallo TurboMagic,
Versuch es mal so:

Delphi-Quellcode:

  {$IF NOT (CompilerVersion < 34.0)}
  FMX.Grid.Style,
  {$ENDIF}

Gruß, Andreas

[TurboMagic]

Zitat:

Zitat von Andreas13 (Beitrag 1492038)

Zitat:

Zitat von TurboMagic (Beitrag 1492036)

Was kann ich da tun?
Das hier versteht die IDE leider nicht:

Delphi-Quellcode:

  {$IF CompilerVersion >= 34.0}
  FMX.Grid.Style,
  {$ENDIF}

Hallo TurboMagic,
Versuch es mal so:

Delphi-Quellcode:

  {$IF NOT (CompilerVersion < 34.0)}
  FMX.Grid.Style,
  {$ENDIF}

Gruß, Andreas

Danke für den Tipp, aber hast du den mal selber ausprobiert?
Der funktioniert nämlich genauso wenig...
AUch hier fügt die IDE diese Unit immer wieder ein.

[TurboMagic]

Hallo,

verstehe noch nicht ganz, was du uns damit sagen willst?
Im 6.2.1 Branch habe ich das mit der FMX schon gelöst, in dem ich nur ab CompilerVersion >= 34.0
StringColumn2.HorzAlign := TTextAlign.Trailing; setze. Danach abe ich das aus der FMX entfernt.

Das klappt schon. Problem ist nur, dass die IDE darauf besteht diese FMX.Grid.Style Unit unbedingt
hinzufügen zu müssen...

Grüße
TurboMagic

[Andreas13]

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

[TurboMagic]

Zitat:

Zitat von Andreas13 (Beitrag 1492041)

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:

Zitat von Michael II (Beitrag 1492012)

"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:

Zitat von Andreas13 (Beitrag 1492046)

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:

Zitat von TurboMagic (Beitrag 1492044)

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:

Zitat von EdAdvokat (Beitrag 1492065)

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;