Page 1 sur 1
Emplacement ReceiveNetworkFile
Publié : mar. 10/juil./2007 16:19
par wolfjeremy
Salut,
J'aimerais savoir, où est stoquer le fichier en cours de téléchargement avec ReceiveNetworkFile.
Il est dans un dossier temporaire ?
Merci d'avance pour votre réponse.
Publié : mar. 10/juil./2007 16:23
par Anonyme
bah... c'est la ou tu le decide ?
tu as lu la doc ?
ReceiveNetworkFile(Connection, FileName$)
++

Publié : mar. 10/juil./2007 17:47
par wolfjeremy
Oui oui le fichier final est là, mais PENDANT le telechargement, le fichier est stoqué dans un autre dossier non ?
P.S.: Cpl.Bator, tu me déçois là mdr comme si j'avais pas vu le parametre

Publié : mar. 10/juil./2007 17:57
par Anonyme
Bah , à mon avis il est en mémoire.
P.S.: Cpl.Bator, tu me déçois là mdr comme si j'avais pas vu le parametre
Ca arrive à tous le monde

Publié : mar. 10/juil./2007 18:04
par wolfjeremy
En faite je voulais faire une barre de progression, en prenant la taille du fichier déjà télécharger et la taille total, je trouve que ça aurait été un bon système.
Dans la mémoire ça me semble bizar quand même, parce que si le fichier fait plusieur Go

(pour les Data ok mais pour un fichier)
Enfin je vais regarder ça.
Sinon on peut toujours divisé le fichier en 100 et a chaque fois que le transfert d'un centième de fichier est fini on ajoute un pourcent à la barre.
Publié : mar. 10/juil./2007 18:11
par Anonyme
le problème à déjà été soumis sur un forum, si je me rappelle bien, pour un fichier
il ne faut pas passé par cette fonction, mais par l'envois de données brut
dans un premier temps tu envois la taille du fichier au client
et ensuite tu envois byte par byte le fichier ( tu le reconstitue de l'autre coté )
tu numérotes les bytes , si la numérotation n'est pas contigüe, alors ta un trou dans le fichier, à toi de renvoyer le numéro manquant.
avec se systeme, rien de plus simple que d'affecté une barre de progression.
Publié : mar. 10/juil./2007 18:34
par wolfjeremy
Oui j'ai pensé à ce système là aussi.
Mais c'est quoi cette histoire de trou ?

Publié : mar. 10/juil./2007 18:40
par Anonyme
en fait, si tu envois octet par octet, il se peut qu'il te manques des parties , (paquet pas recu) il faut les numérotés et les vérifiés.
Publié : mar. 10/juil./2007 19:10
par wolfjeremy
Ok je vois, merci.
J'avais pas pensé à ça.
Publié : mar. 10/juil./2007 20:01
par Anonyme
de rien, si je peut te bouffé les nibars en échange

Publié : mar. 10/juil./2007 20:18
par venom
de rien, si je peut te bouffé les nibars en échange Very Happy
karement

.
@++
Publié : mar. 10/juil./2007 20:53
par minirop
Cpl.Bator a écrit :en fait, si tu envois octet par octet, il se peut qu'il te manques des parties , (paquet pas recu) il faut les numérotés et les vérifiés.
si c'est envoyé en TCP, c'est géré automatiquement le renvoie si perte (mais pas en UDP).
le mieux serait de regarder ton répertoire temp (sans C/Docs and Settings/<user>/temp), mais le nom sera certainement aléatoire. Donc à part regarder combien d'octet reçu, je vois pas)
Publié : mar. 10/juil./2007 21:09
par wolfjeremy
Cpl.Bator a écrit :de rien, si je peut te bouffé les nibars en échange


Vais peut être enlevé cet avatar MDR j'ai déjà eu des MP et tout
minirop a écrit :si c'est envoyé en TCP, c'est géré automatiquement le renvoie si perte (mais pas en UDP).
le mieux serait de regarder ton répertoire temp (sans C/Docs and Settings/<user>/temp), mais le nom sera certainement aléatoire. Donc à part regarder combien d'octet reçu, je vois pas)
Oui c'est en TCP que j'envoie.
Je vais regarder dans le dossier temp on sais jamais (même si là j'ai adopté la metode du byte par byte.)
EDIT: Un peut lent la methode byte par byte.