Gute Neuigkeit! DEC 6.2 soeben released!

[Andreas13]

Hallo Norbert,
den "Helm" kannst Du Deinem Code auch nachträglich über den Punkt "Bearbeiten" aufsetzen. :-D
Gruß, Andreas

[EdAdvokat]

Also, habe soeben Benchmark_FMX auch mit Delphi 10.1 und 10.2 getestet. Diese beiden Versionen benötigen die Einfügung:

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

Also die brauchen FMX.Grid.Style, ...

Auch die Zeile 229 sollte so bleiben wie sie ist: sg_Results.Cells[2, RowIndex] := FStopwatch.Elapsed.ToString;
Mit den Kompilerzeichen streikt das Programm in Delphi 10.1 und 10.2 und vermutlich auch bei 10.3 (werde ich noch probieren)

Also vermutlich gab es zwischen Delphi Seattle und Delphi Berlin den für uns hier signifikanten Wechsel. Also sollte vermutlich < 31 eingefügt werden, damit
die Änderungen nach Seattle vorgenommen werden.

[TurboMagic]

Zitat:

Zitat von EdAdvokat (Beitrag 1492078)

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

Das .ToString habe ich umgesetzt und auch in Cipher_FMX den FMX.Grid.Style Unit Fix angewendet.
Siehe mein Commit. Deine letzte Bemerkung mit .ToString habe ich erst jetzt gesehen und noch
nicht ganz verstanden.

Díe restlichen Sachens schaue ich mir nach dem Mittagessen an.

[philipp.hofmann]

Ich überprüfe die Delphi-Versionen im Code immer folgendermaßen:

Delphi-Quellcode:

{$IF defined(VER330) or defined(VER340)}
      System.Permissions,
{$ENDIF}

[EdAdvokat]

Also Benchmark_FMX mit Delphi 10 Seattle getestet, nachdem ich die Compilerdirektive auf < 31 geändert habe klappt es, da ja auch Zeile 229 ohne tostring geändert wurde.
Also mit < 31 sollte es nun generell klappen.
So auch auch getestet mit Delphi 10.1, Delphi 10.2 und Delphi 10.3. überall mit < 31 ohne erkennbare Beanstandungen.
Soweit erst einmal. Ich denke wir biegen so in eine Zielkurve ein....

[TurboMagic]

Zitat:

Zitat von EdAdvokat (Beitrag 1492084)

Also Benchmark_FMX mit Delphi 10 Seattle getestet, nachdem ich die Compilerdirektive auf < 31 geändert habe klappt es, da ja auch Zeile 229 ohne tostring geändert wurde.
Also mit < 31 sollte es nun generell klappen.
So auch auch getestet mit Delphi 10.1, Delphi 10.2 und Delphi 10.3. überall mit < 31 ohne erkennbare Beanstandungen.
Soweit erst einmal. Ich denke wir biegen so in eine Zielkurve ein....

Interpretiere ich dich richtig, dass mein Commit dieser TStopwatch Abfrage so wie er ist passt?

Ansonsten: habe eben eine Änderung der Cipher_FMX und Hash_FMX Demos commited. Diese compilieren und funktionieren jetzt auch
mit XE8 (das hab' ich hier noch in einer VM gerade installiert). Da hab' ich die Nutzung des IFMXDialogServiceAsync
auf 10.1 Berlin+ beschränkt und sonst halt die alte MessageDlg aufgerufen.

[TurboMagic]

So, jetzt auch noch im HashBenchmark_FMX das AutoDisplace bei den Optionen des String Grids entfernt.
Da wir ja kein Editieren zulassen wollen ist es eh' nutzlos und war mit 10.1 Berlin eingeführt worden.

=> Frage: haben wir jetzt alle Probleme beseitigt?

[EdAdvokat]

nur nochmal zur Selbstverständigung, da ich mit den aktuellen Änderungen stets auf dem letzten Stand sein möchte:
mit der von mir vorgenommenen Änderung in den Compiler-Direktiven hin zu < 31 statt 34 und der von TurboMagic vorgenommenen Änderung der Zeile 229 in Benchmark_FMX ohne "tostring"
sollte es in den von mir geteteten Delphi-Versionen klappen.
Habe ich das richtig verstanden?

[TurboMagic]

Also ich würde einfach die neueste Version hier testen:

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

[EdAdvokat]

Also wie ich bereits zuvor feststellen konnte braucht Delphi Berlin, Tokio und Rio und sicher auch 10.4 das FMX.Grid.Style-Modul.
Wenn wie jetzt eingestellt in den CompilerDirektiven mit < 34 läuft es nicht ! mit < 31 läuft es !
Mit <34 erhalte ich folgende Oberfläche im Benchmarm_FMX und nichts geht mehr:

Für Klasse TStringGrid wurde kein TStyledPresentation Proxy-Nachkomme registerit
Eventuell muss das FMX.Grid.Style Modul in den uses -Abschnitt eingefügt werden.

[TurboMagic]

Sorry, das hatte ich irgendwie überlesen oder so.
Ist jetzt aber in dem Branch gefixt.

Sind wir dann durch?

[EdAdvokat]

also von Seattle, Berlin, Tokio und aus Rio funkt es: Erfolg!!!

Die jeweiligen Programme werfen keine Exception beim Aufruf und offensichtlich stimmt auch sonst alles soweit.

Etwas bewegt mich jedoch - wie hast Du dass Problem mit der Registierung der neuen HashSHA3_512 usw gelöst?

Wäre es auch möglich, nur einzelne Hash-Funktionen relativ unkompliziert in eigene Programme zu verwenden oder hängt da immer
ein gewaltiger Rattenschwanz mit dran?
Die gleiche Frage ergibt sich bei der Verwendung einzelner Chiffreverfahren.
Einfach die nicht benötigten auskommentieren?
Sicher muss ich da nochmals tiefer eintauchen.

[TurboMagic]

Hallo,

am Klassenregistrierungsmechanismus habe ich nichts mehr geändert,
ruft man die Funktion mit vollständigem Klassennamen auf, funktioniert
alles wie gedacht. Dafür ist's da ;-)

Aber:

1. Standardmäßig werden erstmal alle Klassen registriert, es
würde vermutlich also aller Code mit reincompiliert aber:

2. Es gibt inzwischen ein Define "ManualRegisterClasses".
Wenn dieses definiert ist werden gar keine Klassen registriert.
Dann wird durch Smartlinking in Delphi nur das mit reincompiliert/gelinkt,
was du auch benutzt.

3. Den Klassenregistrierungsmechanismus muss man nicht benutzen. Der ist
u.a. drin, weil es das früher schon mal gab und kann in bestimmten
Situationen (wie den FMX Demos für Hashes und Ciphers) nützlich sein oder
wenn man ein verschlüsseltes Dateiformat konstruiert, welches verschiedene
Algorithmen erlaubt. Dann kann man die Identity benutzen und über den
Registrierungsmechanismus eine Instanz des benötigten Algorithmus erzeugen.

Wenn nichts dagegen spricht würde ich diese Fassung dann als 6.2.1 veröffentlichen, ok?

Grüße
TurboMagic

[EdAdvokat]

Also aus meiner ganz bescheidenen Sicht spricht nichts gegen den erneuten Stapellauf! Aber ggf. äußern sich noch andere kompetentere User, denn einige haben das Procedure ja mit
verfolgt und haben vermutlich dazu auch eine Meinung.

[Michael II]

Habe soeben 6.2.1 bugfix... heruntergeladen und installiert. Wenn ich mit 10.4.2 Demos\Cipher_FMX in der IDE starte, dann zeigt mir Delphi an:
Im Projekt Cipher_FMX.exe ist eine Exception der Klasse EReadError mit der Meldung 'Ungültiger Eigenschaftswert' aufgetreten. ---------------
Im Projekt Cipher_FMX.exe ist eine Exception der Klasse EReadError mit der Meldung 'Fehler beim Lesen von ComboBoxCipherAlgorithm.OnChange: Ungültiger Eigenschaftswert' aufgetreten. Das Programm wird beendet.

[EdAdvokat]

ich habe mal die MainForm.pas von Cipher_FMX mit früheren Versionen(06.03.21) verglichen. procedure TFormMain.ComboBoxCipherAlgorithmChange(Sender: TObject): Zeile 279 und folgende
unterscheiden sich lediglich dadurch das jetzt verwendete inttostr und früher .tostring eingesetzt wurde.
Ich habe mal probeweise den alten Zustand mit .tostring wiederhergestellt und bei mir läuft es durch. Sollte also ggf. mit D 10.4.2 getestet werden. Oder hat es mit der alten Version
und D 10.4 da auch schon Probleme gegeben?

[Michael II]

Habe nochmal geladen und installiert - es geht; alles OK.

[TurboMagic]

Zitat:

Zitat von Michael II (Beitrag 1492145)

Habe nochmal geladen und installiert - es geht; alles OK.

Diesen Absturz hatte ich gestern auch mal, nur dann wieder vergessen und die Fehlermeldung ist ja
leider nicht all zu hilfreich. Sagt ja nicht, welche Eigenschaft fslsch ist.

Ich konnte es eben auch nicht mehr anchstellen (in 10,4,2).
Habe eben noch die letzten Anpassungen der Projektdateien (Unit Ausgabeverzeichnis des DUnitX
Projektes korrigiert und Versionshistorie aktualisiert) committed.

Wenn also nichts dagegen spricht würde ich das gegen Abend so veröffentlichen.

[TurboMagic]

So, es ist released:

https://github.com/MHumm/DelphiEncry...ses/tag/V6.2.1

Ich hoffe es passt jetzt alles, damit ich lieber an neuer Funktionalität weiter arbeiten kann.

[EdAdvokat]

Erst einmal Danke für die neue Verson.

In Cipher_FMX hatte ich wieder den komischen Fehler mit der ComboboxCipherAlgorithmus.onChange von heute vormittag. Dann mit "Erstellen" probiert und Fehler kam nicht mehr. Nicht erklärbar.

Eine weitere Frage: Wie geht es weiter, was hast Du geplant? Welche neuen Funktionalitäten sind in Planung?
Gibt es auch Ideen hin zur Richtung asynchroner Algorithmen (Diffie-Hellman-Merkle, RSA usw.)?

[TurboMagic]

Zitat:

Zitat von EdAdvokat (Beitrag 1492155)

Erst einmal Danke für die neue Verson.

In Cipher_FMX hatte ich wieder den komischen Fehler mit der ComboboxCipherAlgorithmus.onChange von heute vormittag. Dann mit "Erstellen" probiert und Fehler kam nicht mehr. Nicht erklärbar.

Eine weitere Frage: Wie geht es weiter, was hast Du geplant? Welche neuen Funktionalitäten sind in Planung?
Gibt es auch Ideen hin zur Richtung asynchroner Algorithmen (Diffie-Hellman-Merkle, RSA usw.)?

Komisch das mit dem Fehler...
Zu Plänen: schrittweise Umsetzung der Algorithmen von denen ich noch
Delphi Code habe. Ich habe z. B. mit Shake128/256 angefangen aber das
liefert noch falsche Werte.

Irgendwann sicher auch asynchrone Algorithmen, vorher aber eher noch
ChaCha und Passwort Hashes. Alles auch abhängig davon wer sonst noch
was beiträgt. GCM Blockverkettung wäre auch gut...

Auch meine Zeit ist endlich...

[TurboMagic]

Ein Besuch der EKON 25 könnte sich evtl. auch lohnen... ;-)

[EdAdvokat]

Habe zwischenzeitlich auch die Adaptionen von Hash_FMX und Cipher_FMX auf VCL-Version neu angepaßt. Im Hash-Programm werden die SHA3_224...SHA3_512 Hash ordnungsgemäß angezeigt.
Alles läuft soweit gut.

Markus, wirst Du auf der EKON 25 einen Beitrag zum Stand des DEC-Projektes halten?
Eine Teilnahme meinerseits ist eher nicht geplant, dazu bin ich doch ein zu lausiger und auch wohl zu alter "Hobby-Programmierer".
Ich beackere ein kleines bescheidenes Feld am Berg "Delphi" und schaue eher ehrfurchtsvoll und demütig auf die Höhen, in denen andere von oben winken.

Ich werde mir die dann veröffentlichten Ergebnisse der EKON ansehen.
Weiterhin alles Gute und gutes Gelingen im DEC-Projekt.

[TurboMagic]

1. Stelle dein Licht nicht so arg unter den Scheffel!

2. Ein vorläufiges Programm findest du hier:
https://entwickler-konferenz.de/programm-de/

[Klapauzius]

Folgender Demo Code funktioniert unter Android 64 mit DEC 6.2 problemlos, macht aber unter Android 32 Probleme:

Delphi-Quellcode:

uses
DECFormat,  DECHash

var
  Hash: THash_MD5;
  FN: String;
begin
  FN:='HalliHallo';
  Hash := THash_MD5.Create;
  Try
    showmessage(Hash.CalcString(FN, TFormat_HEX));
  Finally
    Hash.Free;
  End;

Unter Android 32 Bit (Release) startet die Anwendung nicht, sondern bleibt beim Startupscreen hängen. Kompiliere ich eine Debugversion, startet die Anwendung ohne Probleme. Entferne ich in der Release Konfiguration den Schalter Optimierung, startet das Programm ebenfalls.

[Edited]
Folgender Code reicht bereits, dass die Anwendung unter Android 32 (elease, Optimierung an) nicht startet:

Delphi-Quellcode:

uses
 DECHash

var
  Hash: THash_MD5;
begin

  Hash := THash_MD5.Create;
  Try
    sleep(1000);
  Finally
    Hash.Free;
  End;

[Michael II]

Ist hier auf SM-G770F Android 11, Delphi 10.4U2, SDK 26.1.1. auch wie du's beschreibst.

Es reicht sogar
1. Neues FMX Projekt
2. Im Code:

uses
DECHash;


(
Während dem Kompilieren werden haufenweise
[DCC Hinweis] DECOptions.inc(161): H2586 Alte '$IFEND'-Direktive gefunden. Ändern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND angezeigt.
Das Aktivieren von $LEGACYIFEND bringt keine Besserung.
)


Ohne uses DECHash: funktioniert's wie erwartet. Das Formular wird korrekt angezeigt.

[TurboMagic]

Zitat:

Zitat von Michael II (Beitrag 1492626)

Ist hier auf SM-G770F Android 11, Delphi 10.4U2, SDK 26.1.1. auch wie du's beschreibst.

Es reicht sogar
1. Neues FMX Projekt
2. Im Code:

uses
DECHash;


(
Während dem Kompilieren werden haufenweise
[DCC Hinweis] DECOptions.inc(161): H2586 Alte '$IFEND'-Direktive gefunden. Ändern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND angezeigt.
Das Aktivieren von $LEGACYIFEND bringt keine Besserung.
)


Ohne uses DECHash: funktioniert's wie erwartet. Das Formular wird korrekt angezeigt.

Danke für die weitergehende Analyse dieses mir bereits bekannten Problems.
Die weitere Untersuchung steht schon auf meiner ToDo Liste, aber halt bisher mit geringer Prio.
Mal sehen wann ich dazu komme, ausgehend von euren Untersuchungsergebnissen, weiter nachzuforschen.
Gerne dürft ihr aber auch weitere Analysen durchführen ;-)

Grüße
TurboMagic

[TurboMagic]

Auch wenn ich noch nicht wesentlich zu Untersuchung des Bugs gekommen bin,
habe ich diesen mal hier erfasst:

https://github.com/MHumm/DelphiEncry...dium/issues/26