Entwickler-Ecke
Internet / Netzwerk - Binär-Protokoll - Für Fortgeschrittene mit Delphi 2009/2010
kuba67 - Do 11.02.10 20:44
Titel: Binär-Protokoll - Für Fortgeschrittene mit Delphi 2009/2010
Hallo,
ich möchte das
Binär-Protokoll - Für Fortgeschrittene [
http://www.delphi-library.de/viewtopic.php?t=66706&postorder=asc&start=0]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.
Astat - Fr 12.02.10 16:55
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
Narses - Fr 12.02.10 18:00
Moin!
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. :zustimm:
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). :idea:
Da ich keine Delphi-Version >=2k9 besitze und die Wahrscheinlichkeit, dass sich das jemals ändert, eher gering ist (Spenden sind herzlich willkommen :lol:), werde ich den Code aller Voraussicht nach auch nicht mehr anpassen.
cu
Narses
kuba67 - Fr 12.02.10 23:11
Hy,
ich hatte mir schon sowas gedacht, schade eigentlich ... :lol:
kuba
BenBE - Sa 13.02.10 02:33
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.
Martok - Sa 13.02.10 03:06
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...)
BenBE - Sa 13.02.10 03:09
Ich weiß, aber in einem Tutorial sollte man nicht grad die Bad Practices zeigen, weil jemand mal damit angefangen hat ;-)
kuba67 - Sa 13.02.10 18:05
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 ?
Narses - So 14.02.10 23:44
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. :nixweiss:
| kuba67 hat folgendes geschrieben : |
| Dort scheint die Komponente noch kompatibel zu sein. |
Hä? :gruebel:
| 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. :idea:
cu
Narses
Narses - Fr 19.02.10 18:27
Moin!
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 [
http://www.delphi-library.de/viewtopic.php?p=329873#329873]. :shock:
cu
Narses
//EDIT: Aussage oben korrigiert; ändert aber nix daran, dass der verwendete Code kaputt ist. :nixweiss:
kuba67 - Di 23.02.10 23:46
Hab schon gemerkt, ist nicht ganz unproblematisch.
kuba
kuba67 - So 07.03.10 11:51
cool :wink:
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!