Hallo,

ich möchte das Binär-Protokoll - Für Fortgeschrittene auf Delphi 2009/2010 umstellen und komme nicht weiter.

Im Anhang sende ich meine verwendete Version NarsesBFPA.pas, vielleicht kann sich das mal jemand ansehen ? Beim Compilieren erscheint keine Fehlermeldung, trotzdem muss ich irgend etwas grundsätzliches falsch gemacht haben.

kuba


Moderiert von Christian S.: Topic aus Neue Einträge / Hinweise / etc. verschoben am Fr 12.02.2010 um 11:57
Moderiert von Narses: Original-Code aus dem Tut aus dem Anhang entfernt.

Hallo kuba67, die Ursache ist Unicode ab D2009!

String mit AnsiString; Char mit AnsiChar PChar mit PAnsiChar ersetzen.
Keine Stringroutienen verwenden die Unicode verwenden, problematisch könnten TStrings ab D2009 sein???

Das Protokoll auf Unicode umstellen, würde ich sowieso nicht machen, warum auch?!

lg. Astat

Moin!

kuba67 hat folgendes geschrieben :

ich möchte das Binär-Protokoll - Für Fortgeschrittene auf Delphi 2009/2010 umstellen und komme nicht weiter. [...] Beim Compilieren erscheint keine Fehlermeldung, trotzdem muss ich irgend etwas grundsätzliches falsch gemacht haben.

Astat hat folgendes geschrieben :

die Ursache ist Unicode ab D2009!

So ist es.

Astat hat folgendes geschrieben :

String mit AnsiString; Char mit AnsiChar PChar mit PAnsiChar ersetzen.

Das wäre der erste Teil.

Astat hat folgendes geschrieben :

Keine Stringroutienen verwenden die Unicode verwenden, problematisch könnten TStrings ab D2009 sein?

Das ist der zweite Teil, im Besonderen scheint mir TStringList ab D2k9 auch auf Unicode-Strings zu basieren, was für die Framelisten tödlich ist.

Um es kurz zu machen:
Hiermit rate ich davon ab, diesen Ansatz für Delphi-Versionen >= D2k9 zu verwenden.
Ich habe die Tutorials hauptsächlich zu diaktischen Zwecken entwickelt, der Ansatz ist nicht wirklich für den Produktiv-Einsatz geeignet (aus diversen Gründen, die ich hier mal nicht einzeln auswalzen will, soll ja den Beitrag nicht sprengen). Es ging mir in erster Linie darum, die Technik und das Konzept eines Protokolls zu verdeutlichen. Optimal dafür ist Delphi 7 geeignet.

Für einen Produktiv-Einsatz sollte man sicher besser auf blocking-socket-calls und Threads aufsetzen (wobei ich auch ausdrücklich nicht die Indy-Komponenten empfehle; wer wissen will warum, sollte sich mal ausführlich mit den Kommentaren im QT auseinandersetzen; auch die völlige Inkompatibilität bei einem Versionssprung ist nicht gerade "professionell" zu nennen).

Da ich keine Delphi-Version >=2k9 besitze und die Wahrscheinlichkeit, dass sich das jemals ändert, eher gering ist (Spenden sind herzlich willkommen ), werde ich den Code aller Voraussicht nach auch nicht mehr anpassen.

cu
Narses

Hy,

ich hatte mir schon sowas gedacht, schade eigentlich ...

kuba

Der richtige Ansatz wäre, Array of Byte statt Strings zu nutzen. Man müsste sich dann aber zwei bis drei Hilfsroutinen als Ersatz für die String-Operationen bauen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Richtig wäre, dass Embadingsda die Leute wieder einstellt, die bei Borland die Umstellung von ShortString auf AnsiString gemacht haben.
Da gings doch auch, ohne dass die VCL inkompatibel zu sich selbst wird. Dass die Funktion AnsiUpperCase Unicode zurückgibt, kann ja wohl nicht sein?

Übrigens müsste man mit array of char weniger neu schreiben als viele denken. Sämtliche String-Helper-Funktionen funktionieren auch auf dynamischen arrays (Length, Copy, Insert, Delete, Concat...)

Ich weiß, aber in einem Tutorial sollte man nicht grad die Bad Practices zeigen, weil jemand mal damit angefangen hat

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Die Leute einfach zu entlassen finde ich auch nicht richtig, auch wenns inkompatibel geworden ist, ist ja wohl kein Grund. Jedenfalls hab ich mir überlegt auf die Indy TidTCPClient/TidTCPServer Komponenten zu wechseln. Dort scheint die Komponente noch kompatibel zu sein.

Kann mir vielleicht jemand einen Tip geben wo ich ein gutes Beispiel finde ? Möglichst mit Filetransfer ...

kuba

PS: macht es Sinn den Code aus dem Tutorial auf Indy umzustellen ?

Moin!

kuba67 hat folgendes geschrieben :

Jedenfalls hab ich mir überlegt auf die Indy TidTCPClient/TidTCPServer Komponenten zu wechseln.

Das kann man machen, ist aber auch nicht ganz ohne Fallstricke.

Wenn ich´s neu machen müsste, würde ich direkt in Threads auf die WSA gehen. Das ist weniger abschreckend, als es auf den ersten Blick aussieht und (die Basisfunktionen) bestimmt auch nicht schlechter, als die Jungs der Indy-Crew das umgesetzt haben.

kuba67 hat folgendes geschrieben :

Dort scheint die Komponente noch kompatibel zu sein.

Hä?

kuba67 hat folgendes geschrieben :

macht es Sinn den Code aus dem Tutorial auf Indy umzustellen ?

Nein, sicher nicht. Das Tutorial basiert auf non-blocking-sockets mit Ereignissen, Indy auf blocking-sockets und Threads. Das ist komplett was anderes.

cu
Narses

Hallo,

ich hab mir einen neuen Code zusammengebastelt und erfolgreich in eins meiner Projekte integriert.
Den neuen Code habe ich beim Nachbarn gepostet: www.delphipraxis.net...l&highlight=kuba

Hat mir jedenfalls weitergeholfen, in jeglicher Hinsicht ...

kuba

Moin!

kuba67 hat folgendes geschrieben :

ich hab mir einen neuen Code zusammengebastelt und erfolgreich in eins meiner Projekte integriert. Den neuen Code habe ich beim Nachbarn gepostet: www.delphipraxis.net...l&highlight=kuba

Ich hab mal grad über den Code geschaut: also wenn das in D2k10 sauber läuft, dann würde mich das schon wundern (es wird .ReceiveText() verwendet, das kann nicht klappen EDIT: es klappt doch mit der Methode, die Klasse ist in D2010 nämlich endlich korrekt umgestellt, nur d2k9 liefert hier einen Unicode-String, was falsch ist) ... Noch dazu ist der Code potentiell defekt, da davon ausgegangen wird, dass die Ereignisse synchron zu den Datenpaketen kommen, was allgemein ein schwerer Fehler ist.

cu
Narses

//EDIT: Aussage oben korrigiert; ändert aber nix daran, dass der verwendete Code kaputt ist.

Hab schon gemerkt, ist nicht ganz unproblematisch.

kuba

Moin!

Ich denke, ich werde das Binär-Protokoll-Tutorial ziemlich sicher nicht nochmal neu schreiben, das ist mir einfach zu viel Arbeit.

Aber es sieht so aus, als würde ich mir nochmal die TNBFPA-Kompos vornehmen und unicodesave machen. Mal sehen, wie lange es dauert...

cu
Narses

Moin!

So, sollte klappen und ist hier zu haben.

cu
Narses

cool