FTP-Übertragung langsam

[texti]

Danke Thomas,
auch das werde ich einbauen und ausprobieren (wobei ich deinen Code eher verstehe, als den von HeX0R). PureBasic hat einfach soooo viele Möglichkeiten, die in der Hilfe nicht mal erwähnt werden. Nebenbei: wie steht es aktuell mit PureBasic für den Raspi2? Ich weiß, da gibt es viele Diskussionen und Spekulationen und Für und Wider. ... aber cool wäre es trotzdem
Gruß
Gorden

[texti]

Der Upload mit dem geposteten Code läuft gerade. Habe PureBasic 5.30 32-Bit zu laufen. Wie (und wo) muß ich den Code anpassen, damit die Anzeige auch bei über 4GB sauber läuft? Dachte, daß das mit quad-Variablen sauber läuft.
Gruß
Gorden

[Bisonte]

Das Problem wird die Funktion sein, die Dir deine gesendeten Bytes zurückgibt.
Ich kann nirgendwo in der Hilfe entdecken, dass FTPProgress() ein Quad zurückgibt.
Daher gehe ich davon aus, es ist ein Integerwert, der in der 32Bit Version nur ein Longwert
zurück geben kann.

[ts-soft]

(wobei ich deinen Code eher verstehe, als den von HeX0R)

Naja, der Code wurde 1:1 kopiert , allerdings an andere Stellen.
Du denkst von oben nach unten, so kann man Consolen programmieren, aber keine
Fenster! Du mußt in Ereignissen denken und auf diese Reagieren.
Der Unterschied zwischen Hexors Code implementation und meiner ist nur minimal.
Ich habe den Code traditionell in ein Event-Loop eingebaut, während Hexor dafür
ein Callback gebaut hat. Der Codeaufbau ist fast identisch, wenn ich alles in eine Procedure
gepackt hätte. Die Ereignisse werden bei Hexor auch in Echtzeit abgearbeitet, was unter
Umständen bessere Ergegnisse bringt. Auf jedenfall solltest Du Dich mit beiden Varianten
auseinander setzen und nicht sagen sie seien so unterschiedlich.
Noch wichtiger ist das Denken von oben nach unten abschalten sondern in Ereignissen
denken, natürlich nur beim Eventloop.

Zu den Dateigrössen kann ich nichts sagen, habe es noch nie probiert, FTP nutze ich fertige
Programme, kenne also evtl. Einschränkungen nicht, ausser das FTPS und SFTP nicht funktionieren.

Gruß
Thomas

[Kiffi]

Ich kann nirgendwo in der Hilfe entdecken, dass FTPProgress() ein Quad zurückgibt.

HeX0R hat es ausprobiert: http://www.purebasic.fr/german/viewtopi ... 08#p331108

(Weiß allerdings nicht, ob es mit der Beta3 behoben wurde. Wenn nicht: Wer meldet es?)

Grüße ... Peter

[Bisonte]

Ich kann nirgendwo in der Hilfe entdecken, dass FTPProgress() ein Quad zurückgibt.

HeX0R hat es ausprobiert: http://www.purebasic.fr/german/viewtopi ... 08#p331108

(Weiß allerdings nicht, ob es mit der Beta3 behoben wurde. Wenn nicht: Wer meldet es?)

Grüße ... Peter

Danke... das hab ich wohl überlesen... Man kann sich ja nich alles merken

Wegen Mangel an Ausdrucksfähigkeit in der englischen Sprache, bin ich raus

[texti]

... oh, wußte nicht, daß ich damit so eine grundlegende diskussion anstoßen würde ...
wenn das selbst bei x64-purebasic mit großen zahlen nicht sauber läuft - wie dann?
@RSBasic: doch delay? ich bin verwirrt
gruß
gorden

[texti]

@Thomas: wenn ich das die letzten jahre richtig verstanden habe, ist purebasic prozedural- und nicht objekt-orientiert. ich kann zwar eigenschaften setzen, die aber selber kein event auslösen können, oder?
gruß
gorden

[HeX0R]

Ob Callback (wie mein Beispiel) oder in einer großen Select-Schleife (wie Dein Beispiel) kommt am Ende auf das selbe raus.
Früher gabe es die Callback-Möglichkeit nicht, und man musste bei großen Anwendungen irre große Select/Case Schleifen aufbauen, bei denen man gerne den Überblick verloren hat.
Von daher bevorzuge ich mittlerweile die Callback-Methode, habe aber auch noch jede Menge alte Projekte, die ich bestimmt nicht umbasteln werde.

Du must Dir das so vorstellen:
Sobald WaitWindowEvent() aufgerufen wird, wird ein Event aus der Schlange abgeholt.
Du kannst nun diesen Wert nutzen um deine Select/Case Schleife zu füttern.
Hast Du per Bind...Event einen Callback hinterlegt, wird während des Aufrufs von WaitWindowEvent() einfach noch in den hinterlegten Callback gesprungen (das macht PB dann intern, brauchst Dich nicht mehr drum kümmern).

So kannst Du alles schön auslagern, am besten noch vernünftige Prozedurnamen vergeben und das Ganze wird sehr viel übersichtlicher.

Thema Delay:
Ein Fenster erstellt sehr viel mehr Events, als Du verarbeitest.
Alleine das Verschieben z.B. erzeugt einen Sack voll.
Jedes Delay, dass Du drin hast wird das abholen und dadurch verarbeiten der Events verzögern was im schlimmsten Fall zu unschönen Effekten kommt, wie nur halb fertig gezeichnete Fenster oder auch das "keine Rückmeldung" in der Titelleiste.

[ts-soft]

ist purebasic prozedural- und nicht objekt-orientiert

Hat auch keiner was anderes behauptet. Ereignisgesteuert hat ja auch rein garnichts mit OOP zu tun!

ich kann zwar eigenschaften setzen, die aber selber kein event auslösen können, oder?

Eigenschaften, die zur Laufzeit setzt, sollten kein event auslösen können, jedenfalls keines was Du bearbeiten
müßtest. Es gab oder gibt aber ein paar Ausnahmen, die entweder noch ein Bug sind oder ByDesign

Wichtig ist nur, das alles in einem EventLoop einem Ereignis zugeordnet ist. Wirklich alles. Es darf kein Code ausser-
halb eines Ereignisse ausgeführt werden, da dieser das System vollkommen ausbremst und zu flickern und flackern
führen kann. Ereignisse können auch selbst erschaffen werden, z.B. durch Timer. WaitWindowsEvent(timeout) setzt
auch einen Timer, aber der Betrifft dann das ganze Eventloop und das ist auch nicht so Optimal, aber nicht so schlimm
wie ein WindowEvent() mit Delay(x).

Guck Dir ruhig nochmal die Variante von Hexor an, die ist im Prinzip am effektivsten und es wird alles einem Ereignis zu-
geordnet, wenn Du es auch nicht unbedingt siehst.

So, das muß erstmal reichen, verstehen wirste es dann schon, hoffe ich mal.

Und ich sehe gerade HeXOR war schneller