Discussion :

[Lung]

Y a t'il une autre façon de faire que par le PATH ?

:

Personne n'a d'autres idées ?

[Mac LAK]

Personne n'a d'autres idées ?

Une seule : en général, quand j'arrive devant une infaisabilité, je remets en cause, et dans cet ordre :
- Mon implémentation (=est-ce bien fait ?),
- Ma conception (=est-ce que j'ai pris la bonne solution ?),
- La spécification (=ai-je bien compris le besoin ?),
- Les besoins (=est-ce réellement nécessaire ?).

En cas de problème avéré, je reprends l'étape incriminée, et celles qui en découlent bien sûr... Au bilan final, je ne crois pas être jamais tombé sur quelque chose de réellement nécessaire et infaisable... ;-)

Dans ton cas, les deux premiers me semblent plus ou moins hors de cause, étant donné la simplicité du code et de la fonction.
Donc, on en arrive au point qui fâche : Pourquoi as-tu besoin d'ajouter un chemin au PATH ?

[Lung]

Donc, on en arrive au point qui fâche : Pourquoi as-tu besoin d'ajouter un chemin au PATH ?

Bin, pour indiquer à toutes mes autres applications où trouver les paquets dont elles auront besoin.

[edam]

sur le meme poste ou dans un seul (serveur)

[Lung]

sur le meme poste ou dans un seul (serveur)

Sur le même poste.
Mais, ca doit être fait chez tous les utilisateurs. C'est pour ca que je dois faire un bout de code Delphi pour automatiser ca.

[Mac LAK]

Bin, pour indiquer à toutes mes autres applications où trouver les paquets dont elles auront besoin.

Ben mets une clé spécifique à toi tout seul dans la base de registre, tout simplement...

Ex : HKLM\Software\TheLungCompany\Packages\Path=C:\\Program Files\\TheLungCompany\\Packages\\Bin

Enfin, j'dis ça, j'dis rien...

[Lung]

Comment mes applications pouront deviner quelle clef utiliser pour savoir où se trouve les paquets et autre DLL ?
Je ne comprend pas ...

[Mac LAK]

Comment mes applications pouront deviner quelle clef utiliser pour savoir où se trouve les paquets et autre DLL ?

Ben ce sont tes applications, non ? Et toi, tu sais quelle est la clé à utiliser, n'est-ce pas ?
Donc, tu peux lire cette clé au démarrage du programme, et préfixer tes accès explicitement par ce chemin plutôt que de laisser le système (via PATH) se dépatouiller pour retrouver tes fichiers...

Autre solution : Connaissant le nom d'au moins une DLL, "chercher" au démarrage de l'application, sur les disques locaux, ce fichier et noter son répertoire : les autres DLL/packages sont dans le même.

Encore une autre solution : copier tes DLL dans C:\Windows\System32.

Tu vois le principe ?

[edam]

Comment mes applications pouront deviner quelle clef utiliser pour savoir où se trouve les paquets et autre DLL ?
Je ne comprend pas ...

j'ai déja vu se type de question , qulqu'un qui cherche ces spadrille qui son à ces pattes

[Reisubar]

j'ai déja vu se type de question , qulqu'un qui cherche ces spadrille qui son à ces pattes

?

Il est tout à fait légitime de vouloir installer ses dépendances dans un répertoire qui n'est pas celui de Windows. La méthode de Mac Lak est tout à fait justifiée dans ce cas et ne pose pas de problèmes si les différentes dépendances connaissent bien la bonne et même clé du registre indiquant le répertoire cible.

[edam]

regarde:http://www.developpez.net/forums/viewtopic.php?t=343006
la aussi pedro essaye de cherche si il a aplé destroy

[Lung]

Ben ce sont tes applications, non ? Et toi, tu sais quelle est la clé à utiliser, n'est-ce pas ?
Donc, tu peux lire cette clé au démarrage du programme, et préfixer tes accès explicitement par ce chemin plutôt que de laisser le système (via PATH) se dépatouiller pour retrouver tes fichiers...

Utiliser ma propre clef, je suis d'accord.

Là où je ne vois pas comment faire, c'est quand mes exe auront besoin des paquets VCL, RTL, DBRTL, ...
Comment dire, dans mes applications, que si elles ont besoin de ces paquets, c'est tel chemin ?

[Mac LAK]

Comment dire, dans mes applications, que si elles ont besoin de ces paquets, c'est tel chemin ?

Et la fonction LoadPackage, d'après toi, elle sert à quoi ?

Il faut simplement que tu empêches ton programme de charger automatiquement les packages (c'est une option de compilation, si ma mémoire est bonne), et les charger explicitement, c'est tout.