Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Netzwerke (https://www.delphipraxis.net/14-netzwerke/)
-   -   Delphi Sockets und Fastdnet: gemeinsames Schicksal? (https://www.delphipraxis.net/4379-sockets-und-fastdnet-gemeinsames-schicksal.html)

woki 26. Apr 2003 18:24


Sockets und Fastdnet: gemeinsames Schicksal?
 
Hallo,

ich habe ein Projekt, daß ich unter Delphi7 von Fastnet auf Indy umstellen will, aber um das Projekt überhaupt erstm,al laden und dann Schritt für Schritt umstellen zu können, wäre es sehr hilfreich diese unter Delphi 7 überhaupt zuf Verfügung zu haben, gibt es da eine Lösung wie bei den Sockets (Borland Internetkomponenten)?

siehe auch Thread
Zitat:

Socket.sendtext unter Delphi 7
Grüsse
Wolfgang

Ulrich Wolf 15. Dez 2003 08:14

Re: Sockets und Fastdnet: gemeinsames Schicksal?
 
Hallo,
ich habe das gleiche Problem. Ein in Delphi5 geschriebenes Programm soll mit Delphi7 verändert werden. Beim Aufruf bringt er schon fehlermeldungen - also nichts mit Abwärtskompatibilität! :twisted: Nun suche ich eine Transferliste, wie die alten FastNet -Befehle in die neuen INDY-Befehle zu schreiben sind. Bei Borland habe ich eine solche Transfehrliste nicht gefunden. Wer kann uns helfen?

woki 15. Dez 2003 08:34

Re: Sockets und Fastdnet: gemeinsames Schicksal?
 
Hallo,

die Fastnet - Komponenten sind Drittherstellerkomnponenten von denen Borland sich verabschiedet hat. Du könntest prüfen, ob es für dein Projekt Sinn macht, diese Kompnenten von Fastnet zu erwerben und nicht umzustellen. Für mich war das keine Alternative.

Für die Transferliste würde ich mir nicht allzuviel Hoffnung machen. Dazu sind die Technologien zu unterschiedlich und niemand wird sich für eine solche Arbeit verantwortlich fühlen.

Grüsse
Woki

DataCool 15. Dez 2003 14:51

Re: Sockets und Fastdnet: gemeinsames Schicksal?
 
Hi,

ausserdem sind die Indy Komponenten vom Aufbau und vom Grunsgedanken komplett anderes als die Fastnet !

Indy arbeitet durchgehend mit Blocking Sockets, wo man sich als FastNet User erstmal dran gewöhnen muss.

Ich habe mit beiden(FastNet und Indy) schon gearbeitet, würde jetzt aber nicht mehr auf die Indy Komponenten verzichten wollen.

Wo genau habt Ihr Probleme bei der Portierung ?

Gruß Data

woki 15. Dez 2003 15:00

Re: Sockets und Fastdnet: gemeinsames Schicksal?
 
Hallo,

Na ja, wie gesagt, wenn die (Fastnet) Komponenten nicht zur Verfügung stehen, kann man die Projekte nicht wie gewohnt in die IDE laden, was die Umstellungsarbeit unangenehmer macht.

Grüsse
Woki

Ulrich Wolf 16. Dez 2003 08:59

Re: Sockets und Fastdnet: gemeinsames Schicksal?
 
Hallo,
mit NMHTTP gibt es verschiedene Proceduren. Unter anderem

----------------------------------------------------------
type
TForm1 = class(TForm)
....
NMHTTP1: TNMHTTP;
....
procedure NMHTTP1PacketRecvd(Sender: TObject);
procedure NMHTTP1Success(Cmd: CmdType);
....
....
if SVers <> Label12.Caption then
begin
Label12.Caption := SVers;
NMHTTP1.Body :=('C:\Programme\IMC-Server\Update-Server\IMC Server.exe');
NMHTTP1.Get(Edit1.Text);
end;
....
Ab hier beginnen die Prozeduren für die Komponente NMHTTP }

procedure TForm1.NMHTTP1PacketRecvd(Sender: TObject);
begin
EmpfangeneBytes:=FormatFloat('#,##0',NMHTTP1.Bytes Recvd);
BytesInsgesamt:=FormatFloat('#,##0',NMHTTP1.BytesT otal);
StatusBar1.panels[0].text:=EmpfangeneBytes+' Bytes von '+
BytesInsgesamt+' Bytes empfangen';
end;

procedure TForm1.NMHTTP1Success(Cmd: CmdType);
begin
GesendeteBytes:=FormatFloat('#,##0',NMHTTP1.BytesS ent);
StatusBar1.panels[0].text:='Fertig ('+
EmpfangeneBytes+' Bytes empfangen).';
beep;
ShellExecute(0,
Nil,
PChar('C:\Programme\IMC-Server\Update-Server\Updater IMC Server.exe'),
Pchar('-Parameter'),
Pchar('C:\StartDir'),
SW_NORMAL);
Form1.Close;
end;
------------------------------------------------------------

So weit die Fragmente der NMHTTP Befehle.
Vilen Dank für die Hilfe
Viele Grüße


Alle Zeitangaben in WEZ +1. Es ist jetzt 02:52 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz