OVH Cloud OVH Cloud

Comment copier un fichier sur Internet ???

3 réponses
Avatar
LE TROLL
Bonjour,

Problème simple, j'ai besoin d'une part de copier le fichier sous-cité
depuis Internet dans le répertoire de mon application:

http://www.fdjeux.com/generated/dyn/loto/loto.zip

Puis de le déziper afin de pouvoir le lire (texte norme csv).

Je ne sais ni comment copier le fichier automatiquement en VB, ni le
déziper de la même façon.
Si possible j'ai une préférence pour le code, à défaut les API, a contrario
des objet additionnels qui causent toujours des problèmes un jour ou
l'autre...

Si vous pouvez m'aider :o)

--
Merci beaucoup, au revoir et à bientôt :o)
------
Site de MES LOGICIELS
http://irolog.free.fr
Site éditeur de MES ROMANS édités
http://irolog.free.fr/romans
mon adresse EMail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------

3 réponses

Avatar
Picalausa François
Hello,

Bien que ça ait été à titre humoristique, je trouve la remarque déplacée, en
ce sens que Jean-Marc (ou tout autre intervenant de ce groupe d'ailleurs)
consacre un temps et une énergie assez considérable pour la communauté. Plus
particulièrement, je crois pouvoir dire que c'est grâce à ses contributions
que la faq vb est à nouveau active! Je n'ai peut-être pas un sens de
l'humour assez fin que pour apprécier la plaisanterie; je trouve qu'elle est
irrespectueuse envers le seul MVP de ce groupe! Bien entendu, ce n'est que
mon point de vue, et je ne peut parler à sa place.

Soit! Tu indiquais préférer du "code" aux APIs. Je suppose que le "code"
dont il s'agit est le subset de VB sans appels à quelque autre composant
externe (pas de référence, pas de declare function, ...)
Dans ce cas, je te propose plutôt la solution suivante:
Pour télécharger le fichier, crée un usercontrol et emploie la méthode:
UserControl.AsyncRead Url, vbAsyncTypeFile, Fichier

A noter le dernier argument qui permet en plus de définir comment le
téléchargement doit être effectué.
Si le téléchargement doit être synchrone (comme dans ton cas) par exemple:
vbAsyncReadSynchronousDownload

Tu pourra éventuellement récupérer l'état du téléchargement à l'aide de:
UserControl_AsyncReadComplete
UserControl_AsyncReadProgress

Pour ce qui est du chemin, je te déconseille vivement App.Path.
La faq est très précise à ce sujet:
http://faq.vb.free.fr/index.php?question3 (Sauvegarde dans un fichier >
Destination des fichiers)
Pour ne pas utiliser d'APIs, il existe la possibilité d'utiliser environ.
Pour une compatibilité maximale avec Win 9x, la variable d'environnement
TEMP pourrait être à privilégier. Je te laisse le soin d'étudier la
question.

Enfin, apparement, d'après mes recharches, ton code se base plutôt sur un
wrapper de zlib (donc redistribuable et approprié) que sur une dll winzip.
Voir à ce sujet:
http://www.paradoxes.info/code/ZipExtractionClass.html
Il est aussi possibilté d'éviter toute référence externe (ce qu'on apelle
API en d'autres termes) en implémentant la partie utile de la specification
zip:
http://www.pkware.com/index.php?option=com_content&task=view&idd&Itemid7

--
Picalausa François

"LE TROLL" <le a écrit dans le message de news:
%
Ben j'ai trouvé tout seul !

Le mvp de permanence devait encore dormir, pourtant ils sont bien
payés, alors je propose que le mvp de permanence laisse ici son numéro de
téléphone, comme ça si on a besoin de lui en pleine nuit, on peut
l'appeler :o)

Voici le code, il faut aussi une un module de classe et une dll
(fournie normalement avec WinZip), ci-joint en 2 fichiers, au cas où ça
intéresserait quelqu'un (l'extraction sur Internet d'un zip depuis vb):


' loto form1
'
Option Explicit
Private Declare Function URLDownloadToFile Lib "urlmon" Alias
"URLDownloadToFileA" _
(ByVal pCaller As Long, ByVal szURL As String, ByVal szFileName As
String, _
ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
'
Sub Form_Load()
ChDrive App.Path
ChDir App.Path
End Sub

Sub Command1_Click() 'tél loto
Dim dest As String
Dim adr As String
Dim rep
Dim zip As ZipExtractionClass
Set zip = New ZipExtractionClass
'
adr = "http://www.fdjeux.com/generated/dyn/loto/loto.zip"
dest = App.Path & ""
dest = dest & Mid$(adr, 1 + InStrRev(adr, "/")) ' /loto.zip
rep = URLDownloadToFile(0&, adr, dest, 0&, 0&)
'
DoEvents ' à améliorer au timer avec -> tant que fichier inexistant et
arrêt manuel...
Sleep 5000
'
rep = zip.OpenZip(dest)
rep = zip.Extract(App.Path & "")
zip.CloseZip
Set zip = Nothing
'
Unload Form1
End
End Sub
"LE TROLL" <le a écrit dans le message de news:
O8r%
Problème simple, j'ai besoin d'une part de copier le fichier sous-cité
depuis Internet dans le répertoire de mon application:

http://www.fdjeux.com/generated/dyn/loto/loto.zip

Puis de le déziper afin de pouvoir le lire (texte norme csv).




Avatar
LE TROLL
Bonjour François,

En effet c'était de l'humour, et effectivement Jean-Marc effectue une
remarquable prestation, Jacques aussi m'a aidé... Alors comme tu dis que tu
n'as peut être pas l'humour assez fin, je ne puis que t'encourager à
l'affiner :o)

Heu, je ne suis pas certain de mettre bien expliqué, en fait je
privilégie le code VB et les objets (composants) de base (ceux qui ne sont
pas à rajouter manuellement avec me menu), car presque tous les jours on
voit les problèmes engendrés: qui a une base de données qui ne reconnaît
plus ses petits, et qui a un webBroser qui coince avec l'IE7, qui a un
graphisme ou un Calendar en rade à cause des dll...
J'en suis même arrivé à dessiner mes graphismes au pixel sur la feuille, et
ça c'est du béton, ça ne bouge plus! Tout comme les fichiers, texte ou
binaire, je ne fais que ça, pareil, ça marche depuis 30 ans, depuis le CPM,
ça ne plante jamais, du sérieux!

D'ailleurs tu cites la faqVB 143, voici ce qu'elle dit:
"Il y a un cependant des inconvénients à l'utilisation des BDD. On citera :
l'application n'est plus autonome, elle dépend pour son fonctionnement d'une
technologie tierce, le déploiement implique l'installation sur les postes
clients des fichiers nécessaires à la gestion de la BDD (moteur Jet pour
Access, etc.).
Tout est dit, comme je le dis, sauf pou un salarié obligé de passer par une
BDD, la bonne programmation c'est les fichiers texte et binaires (la bonne,
dans le sens, celle qui fonctionne dans le temps sans problème), comme quoi
je n'ai pas si tort que ça, ce qui me rassure... Il y a aussi Etienne qui
est bon, mais qu'on voit moins, qui avoue préférer faire ses propres
fichiers, plutôt que de faire du paramétrage de BDD... En fait il n'y a rien
de plus sérieux à mon sens que le bon vieux fichier texte, que tu peux
contrôler à l'oeil nu, et qui ne crève jamais, et qui va aussi vite qu'un
moteur de BDD...

En sus, je ne vois pas le plaisir qu'il y a paramétrer, à définir des clefs,
des datas, à cocher des croix, ce n'est pas la peine de faire de la
programmation pour ça, suffit d'un stage de paramétrage... Bref, j'aime la
vraie programmation avec du code!
Et encore mieux, s'il y a de la place j'embarque le maximum de données dans
l'exe, dans le code, ça évite le piratage et les fichier à joindre lord de
l'installation...
En dernier, dans le cadre associatif (hum), je fais des logiciels comme tu
le sais, et un logiciel si jamais il plante, tu perds un "client", tu te
fais incendier, voire à devoir rembourser... Alors il faut que ça tourne
toujours, qu'els que soient les modifications, et notamment les version de
dll... Ce sont en effet des contraintes différentes du milieu de
l'entreprise, ou il y a en permanence des informaticiens qui règlent le
problème, là, le particulier ne sait pas régler son problème, si son
logiciel ne tourne plus, il accuse le concepteur...

Concernant les API, le problème c'est que ce n'est pas VB, alors je les
utilise en second (après le code et les objets de base), quand je ne peux
faire autrement. Déjà, parfois je vois des personnes qui font des
application, rien qu'avec des API, or ce n'est plus la peine de se référer à
VB dans ce cas, il suffit de prendre un vieil éditeur gratuit de code, et de
compiler les API, ça sort du cadre VB.
Le second problème est que les API sont aussi dépendantes des DLL, certes,
mais encore que c'est totalement incompréhensible, les abréviations sont en
anglais, alors ça donne en français des noms barbares inexpressifs, c'est
souvent gros juste pour faire un petit truc, on met des paramètres, on ne
sait même pas pourquoi, c'est très mal documenté, difficilement lisible et
compréhensible.
Je crois que c'était dans l'éditeur de c++ Builder, où on voyait le corps
des API, il me semble? Enfin bref, c'était déjà plus compréhensible car tu
voyais à qui correspondait à tes paramètres, mais avec VB, directement on ne
voit rien, c'est parfois réellement mystique.
Dans mon problème de Net, n'ayant pas trouvé autre chose, j'ai pris le
module de classe avec les API et une pseudo-DLL, mais là je n'avais à ma
connaissance (limitée), le choix de faire autrement, sinon j'évite.

Voici donc les raisons du choix de mes préférence (le code vb), à défaut
(les API), à défaut (les objets-composants additionnels)...

Heu, ta faq vb 143 ne parle pas de App.Path, enfin, je n'ai pas trouvé?
App.Path définit le dossier courant si on l'assimile au disque puis au
dossier, je n'ai jamais eu de problèmes, je conçois tout dans le dossier du
programme (voir un sous-dossier), et ça marche du tonnerre, quel est le
problème ?

Je vais jeter un oeil à "TEMP"

C'est donc toi qui es de permanence pour la fin de semaine :o)

Merci encore François, à bientôt.

Joe.



--
Merci beaucoup, au revoir et à bientôt :o)
------
Site de MES LOGICIELS
http://irolog.free.fr
Site éditeur de MES ROMANS édités
http://irolog.free.fr/romans
mon adresse EMail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------
"Picalausa François" a écrit dans le message de news:

Hello,

Bien que ça ait été à titre humoristique, je trouve la remarque déplacée,
en ce sens que Jean-Marc (ou tout autre intervenant de ce groupe
d'ailleurs) consacre un temps et une énergie assez considérable pour la
communauté. Plus particulièrement, je crois pouvoir dire que c'est grâce
à ses contributions que la faq vb est à nouveau active! Je n'ai peut-être
pas un sens de l'humour assez fin que pour apprécier la plaisanterie; je
trouve qu'elle est irrespectueuse envers le seul MVP de ce groupe! Bien
entendu, ce n'est que mon point de vue, et je ne peut parler à sa place.

Soit! Tu indiquais préférer du "code" aux APIs. Je suppose que le "code"
dont il s'agit est le subset de VB sans appels à quelque autre composant
externe (pas de référence, pas de declare function, ...)
Dans ce cas, je te propose plutôt la solution suivante:
Pour télécharger le fichier, crée un usercontrol et emploie la méthode:
UserControl.AsyncRead Url, vbAsyncTypeFile, Fichier

A noter le dernier argument qui permet en plus de définir comment le
téléchargement doit être effectué.
Si le téléchargement doit être synchrone (comme dans ton cas) par exemple:
vbAsyncReadSynchronousDownload

Tu pourra éventuellement récupérer l'état du téléchargement à l'aide de:
UserControl_AsyncReadComplete
UserControl_AsyncReadProgress

Pour ce qui est du chemin, je te déconseille vivement App.Path.
La faq est très précise à ce sujet:



http://faq.vb.free.fr/index.php?question3


(Sauvegarde dans un fichier >
Destination des fichiers)
Pour ne pas utiliser d'APIs, il existe la possibilité d'utiliser environ.
Pour une compatibilité maximale avec Win 9x, la variable d'environnement
TEMP pourrait être à privilégier. Je te laisse le soin d'étudier la
question.

Enfin, apparement, d'après mes recharches, ton code se base plutôt sur un
wrapper de zlib (donc redistribuable et approprié) que sur une dll winzip.
Voir à ce sujet:
http://www.paradoxes.info/code/ZipExtractionClass.html
Il est aussi possibilté d'éviter toute référence externe (ce qu'on apelle
API en d'autres termes) en implémentant la partie utile de la
specification zip:
http://www.pkware.com/index.php?option=com_content&task=view&idd&Itemid7

--
Picalausa François

"LE TROLL" <le a écrit dans le message de news:
%
Ben j'ai trouvé tout seul !

Le mvp de permanence devait encore dormir, pourtant ils sont bien
payés, alors je propose que le mvp de permanence laisse ici son numéro de
téléphone, comme ça si on a besoin de lui en pleine nuit, on peut
l'appeler :o)

Voici le code, il faut aussi une un module de classe et une dll
(fournie normalement avec WinZip), ci-joint en 2 fichiers, au cas où ça
intéresserait quelqu'un (l'extraction sur Internet d'un zip depuis vb):


' loto form1
'
Option Explicit
Private Declare Function URLDownloadToFile Lib "urlmon" Alias
"URLDownloadToFileA" _
(ByVal pCaller As Long, ByVal szURL As String, ByVal szFileName As
String, _
ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
'
Sub Form_Load()
ChDrive App.Path
ChDir App.Path
End Sub

Sub Command1_Click() 'tél loto
Dim dest As String
Dim adr As String
Dim rep
Dim zip As ZipExtractionClass
Set zip = New ZipExtractionClass
'
adr = "http://www.fdjeux.com/generated/dyn/loto/loto.zip"
dest = App.Path & ""
dest = dest & Mid$(adr, 1 + InStrRev(adr, "/")) ' /loto.zip
rep = URLDownloadToFile(0&, adr, dest, 0&, 0&)
'
DoEvents ' à améliorer au timer avec -> tant que fichier inexistant et
arrêt manuel...
Sleep 5000
'
rep = zip.OpenZip(dest)
rep = zip.Extract(App.Path & "")
zip.CloseZip
Set zip = Nothing
'
Unload Form1
End
End Sub
"LE TROLL" <le a écrit dans le message de news:
O8r%
Problème simple, j'ai besoin d'une part de copier le fichier
sous-cité
depuis Internet dans le répertoire de mon application:

http://www.fdjeux.com/generated/dyn/loto/loto.zip

Puis de le déziper afin de pouvoir le lire (texte norme csv).








Avatar
Picalausa François
Hello,

<inline>

"LE TROLL" <le a écrit dans le message de news:

Heu, je ne suis pas certain de mettre bien expliqué, en fait je
privilégie le code VB et les objets (composants) de base (ceux qui ne sont
pas à rajouter manuellement avec me menu), car presque tous les jours on
voit les problèmes engendrés: <snip>



Je connais assez ta position sur le sujet. Et c'est pourquoi je t'ai proposé
des solutions n'employant que du VB.

Dans mon problème de Net, n'ayant pas trouvé autre chose, j'ai pris le
module de classe avec les API et une pseudo-DLL, mais là je n'avais à ma
connaissance (limitée), le choix de faire autrement, sinon j'évite.



D'où l'utilité de ma réponse; en passant par un usercontrol dans ton projet,
tu évite la dépendance à la dll en question.

Heu, ta faq vb 143 ne parle pas de App.Path, enfin, je n'ai pas trouvé?



Si si... mais en texte plutôt qu'en code (la partie utile entre **):
<quote src="http://faq.vb.free.fr/index.php?question3">
Si votre application doit pouvoir fonctionner en présence de restrictions de
droits d'accès sur les fichiers (par exemple, en compte utilisateur
restreint sous Windows XP), il faudra vous demander quelles sont les
permissions dont vous avez besoin pour les fichiers utilisés. Le choix du
dossier de destination a donc toute son importance. Pour un accès simple en
lecture, le *dossier de l'application* peut être approprié. *Ne supposez
toutefois pas avoir un droit en écriture sur ce dossier* !
</quote>

App.Path définit le dossier courant



Non... ça c'est la fonction de CurDir

si on l'assimile au disque puis au dossier, je n'ai jamais eu de
problèmes, je conçois tout dans le dossier du programme (voir un
sous-dossier), et ça marche du tonnerre, quel est le problème ?



Je vais encore citer l'article 143:
<quote src="http://faq.vb.free.fr/index.php?question3">
Il est à noter que la gestion d'erreurs relatives à la restriction de droits
est nécessaire afin d'assurer que l'utilisateur ne perde pas son travail
pour avoir tenté d'enregistrer un fichier dans un dossier ne lui étant pas
accessible!
</quote>

En d'autres termes, le dossier de l'application est généralement
inapproprié. Si tu n'as jamais eu de problème, c'est probablement que tu ne
travailles pas en tant qu'utilisateur restreint!
Cela étant, si pour des petites applications maison, c'est acceptable, dès
lors que tu dois te soucier de redistribuer l'application ce genre de
problèmes doivent être testés et pris particulièrement au sérieux!

Je vais jeter un oeil à "TEMP"

C'est donc toi qui es de permanence pour la fin de semaine :o)



Malheureusement, ce n'est pas en un post que j'ai su affiner mon humour :-)

François