Personne n'a d'autres idées ?Citation:
Envoyé par Lung
:hola:
Version imprimable
Personne n'a d'autres idées ?Citation:
Envoyé par Lung
:hola:
Une seule : en général, quand j'arrive devant une infaisabilité, je remets en cause, et dans cet ordre :Citation:
Envoyé par Lung
- 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 ?
Bin, pour indiquer à toutes mes autres applications où trouver les paquets dont elles auront besoin.Citation:
Envoyé par Mac LAK
:wink:
sur le meme poste ou dans un seul (serveur)
Sur le même poste.Citation:
Envoyé par edam
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.
Ben mets une clé spécifique à toi tout seul dans la base de registre, tout simplement...Citation:
Envoyé par Lung
Ex : HKLM\Software\TheLungCompany\Packages\Path=C:\\Program Files\\TheLungCompany\\Packages\\Bin
Enfin, j'dis ça, j'dis rien... :mrgreen:
Comment mes applications pouront deviner quelle clef utiliser pour savoir où se trouve les paquets et autre DLL ?
Je ne comprend pas ...
:koi:
Ben ce sont tes applications, non ? Et toi, tu sais quelle est la clé à utiliser, n'est-ce pas ?Citation:
Envoyé par Lung
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 ?
:zzz:Citation:
Envoyé par Lung
j'ai déja vu se type de question , qulqu'un qui cherche ces spadrille qui son à ces pattes
?Citation:
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.
regarde:http://www.developpez.net/forums/viewtopic.php?t=343006
la aussi pedro essaye de cherche si il a aplé destroy :bug:
Utiliser ma propre clef, je suis d'accord.Citation:
Envoyé par Mac LAK
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 ?
:koi:
Et la fonction LoadPackage, d'après toi, elle sert à quoi ? :mrgreen:Citation:
Envoyé par Lung
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.