Delphi10 et Indy10 : où est TidStreamVCL ?

Bonjour.
Je dispose de Delphi10 Pro sous Windows 7 et donc de Indy10.
Ma connection à Internet se fait par une LiveBox que j'ai configurée pour permettre l'accès entrant à mon poste en local.
Je souhaite échanger un fichier avec des postes connectés sur internet.
Dans la faq Delphi, "reisubar" donne une réponse complète à cette question en utilisant TidStreamVCL. Malheureusement, je ne dispose pas de cet objet dans ma version Pro de Delphi !!!!
Mes recherches n'ayant pas abouti, ma question est donc :
où peut-on trouver la dll contenant TidStreamVCL ?
Merci d'avance.

Apparemment la classe est devenue: TIdStream

Edit: j'ai dit une bêtise, ça m'apprendra à rechercher trop vite.

Delphi 10 = Delphi 2007 ?
J'ai à la fois Indy 9 et Indy 10 dans mon dossier
CodeGear\BDS\5.0\Source\Indy\Indy9\IdStream.pas - non trouvé
CodeGear\BDS\5.0\Source\Indy\Indy10\System\IdStreamVCL.pas - J'ai au mieux une TIdStreamHelperVCL

Citation:

---

Envoyé par cmali67

Mes recherches n'ayant pas abouti, ma question est donc

---

:recherch:
Pense à Rechercher du forum, on y trouve rapidement Undeclared identifer TIdStreamVCL dont les liens indique la suppression de cette classe TIdStreamVCL dont l'utilité semble discutable, son but était de simplifier le code entre Indy VCL et Indy.NET

Il va falloir retirer cette classe intermédiare et manipulé directement le TMemoryStream !

Citation:

---

Envoyé par cmali67

où peut-on trouver la dll contenant TidStreamVCL ?

---

Pourquoi parles-tu de DLL ?
C'est soit dans un fichier .PAS comme IdStream.pas contenant TIdStream ou IdStreamVCL.pas contenant TIdStreamHelperVCL
C'est soit dans un BPL si tu utilises la compilation avec paquet d'éxécution mais cela ne change pas le uses !

J'aurais dû, c'est sûr, rechercher dans le forum, sauf que je n'avais pas vu la case "Recherche" !! Manque de pratique sans doute.
J'ai utilisé TMemoryStream, avec SaveToFile et LoadFromFile.
Si je lance l'envoi du fichier à partir du Client.exe en double clickant sur son icône vers le Serveur en mode déboguage, le transfert est parfait !!!!
Mais si je lance l'envoi du fichier à partir du Client.exe vers le Serveur.exe en double-clickant sur leurs icônes respectives, le flux n'est pas récupéré par le serveur et le transfert ne se fait pas.
Compte tenu de ma faible culture en informatique, il m'est impossible de comprendre ce phénoméne. J'ai toujours été convaincu que le fichier .exe en mode compilation par "F9" devait avoir le même comportement que le fichier .exe lancé en double-clickant sur son icône.
Je reste donc bloqué et plus que perplexe, avec un futur bien sombre pour la suite de mon projet.
Où peut bien se nicher l'erreur ?
Merci d'avance pour vos éclairages.

tu indiques un nom complet de fichier : c:\dossier\sous-dossier\fichier.ext ?
Entre F9 et double-clic, le dossier courant peut être différent, ainsi que les variables d'environnement

Il ne peut s'agir d'un problème de nom de fichier puisque ça fonctionne en faisant F9.
Pour l'environnement, pourquoi pas. Mais dans ce cas, comment fait-on pour s'en affranchir?
Ne pourrait-il pas s'agir d'un problème dr Thread? J'ai en effet le serveur et le client sur mon PC et j'essaie de transférer un fichier d'un dossier (client) vers un autre dossier (serveur), sur le Host 127.0.0.1.
Par ailleurs, j'envoie le fichier dans un MemoryStream et je le récupère dans un FileStream car je n'ai pas trouvé, dans l'aide, la méthode MemoryStream.SaveToFile.
Mais, comme je l'ai dit, ça fonctionne parfaitement par F9 pour le Serveur et double clic sur le Client.exe.
Merci d'avance.

J'ai placé un mémo sur la fiche Serveur pour y afficher les résultats de chaque ligne de code.
Je constate
-que le nom de fichier est bien transféré,
-que le nom de fichier destination (NomFichier) est correct avec son chemin complet
-mais que le flux n'est pas créé par fStream:= TFileStream.Create(NomFichier,fmCreate).
Si je fais F9 sur Dephi, ce flux est créé sans problème.
Voilà une information complémentaire qui peut peut-être aider pour trouver une solution.

Peut-être l'UAC avec son VirtualStore, les fichiers ini par exemple ne sont pas forcément là ou l'on pense !
TFileStream renvoie une exception, tente un GetLastError (si c'est pas trop tard)
tente un CreateFile (API Windows)

Avec CreateFile je me retrouve dans la même situation : impossible de créer le flux fichier exigé par ReadStream.
Je vais demander à un ami de venir chez moi avec son portable.
Nous pourrons constituer un réseau local (je suis actuellement seul sur ce réseau) et échanger par nos adresses 192.165.1.x. Nous verrons alors s'il y a un conflit entre le Client et le Serveur lorsqu'ils communiquent sur un même poste.
Je ne vois plus d'autre solution.
Je donnerai de mes nouvelles après cet essai.

Le Fichier lu par le client est différent du fichier écrit par le serveur ?

En F9, si tu débug, tu ralentis le serveur qui, du coup, peut écrire dans un fichier qui n'est pas bloqué par un autre process (le client)

Le fichier lu par le Client et le fichier écrit par le Serveur portent le même nom mais sont dans des dossiers différents.
J'ai déjà fait l'essai de ralentir le client par un Sleep(500) mais sans résultat.
J'ai réssayé ce matin en mettant un Sleep(500) avant chaque Write mais sans plus de résultat.
Avec le Client et le Serveur sur 2 PC différents, les process ne devraient pas se contrarier. Cet essai sera fait au plus tard dans 3 jours.

L'essai vient de se terminer. Sans succès. TFileStream non créé.
Que peut-on faire??

Du nouveau. Le fichier est transféré sur une clé USB selon la séquence suivante :

Code:

---

1 2 3 4 5 6 7

sFileName:= 'G:\' + sLine; // G = clé USB hFile:= FileCreate(sFileName); FileClose(hFile); mStream:= TMemoryStream.Create; iStreamSize:= ReadInt64(); ReadStream(mStream,iStreamSize,False); mStream.SaveToFile(sFileName);

---

Si on remplace G par C, mStream.SaveToFile(sFileName) produit une erreur, même lorsque le flux est envoyé à partir d'un autre ordinateur sur le réseau !!!!
Mon problème n'est donc pas complétement réglé. Mais cette information peut peut-être faire entrevoir une explication.

Si le fichier est du style "c:\toto.txt' sous un windows 7 avec UAC, c'est normal que cela ne fonctionne pas car L'os n'autorise pas l'écriture de fichier direct à la racine de C

Effectivement. Le problème est donc résolu.
Derrière C:\ , se trouve pourtant le fichier C:\PDOXUSRS.NET sur mon ordinateur, tout seul il est vrai.
S'il n'avait pas été là, j'aurais peut-être été alerté.
Toujours ce manque de connaissances de base!!
Merci infiniment pour le temps passé sur mon cas. Je vais pouvoir enfin continuer mon projet.