Fred a écrit le 09/12/2007 :Voir la procèdure :
ResolveDestDir dans le module basSetup1.basEt tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
Fred a écrit le 09/12/2007 :
Voir la procèdure :
ResolveDestDir dans le module basSetup1.bas
Et tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
Fred a écrit le 09/12/2007 :Voir la procèdure :
ResolveDestDir dans le module basSetup1.basEt tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
aski a écrit :Fred a écrit le 09/12/2007 :Voir la procèdure :
ResolveDestDir dans le module basSetup1.basEt tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
Absolument, j'y avais fais des modifications pour créer des raccourcis
sur le bureau et dans Menu Démarrer sous ... Windows 95 ;-)
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
aski a écrit :
Fred a écrit le 09/12/2007 :
Voir la procèdure :
ResolveDestDir dans le module basSetup1.bas
Et tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
Absolument, j'y avais fais des modifications pour créer des raccourcis
sur le bureau et dans Menu Démarrer sous ... Windows 95 ;-)
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
aski a écrit :Fred a écrit le 09/12/2007 :Voir la procèdure :
ResolveDestDir dans le module basSetup1.basEt tu l'as déjà examiné !
Il ne te reste plus qu'à l'adapter ;-)
y-en a qui ont essayé lol rofl lol
Absolument, j'y avais fais des modifications pour créer des raccourcis
sur le bureau et dans Menu Démarrer sous ... Windows 95 ;-)
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
Mais je persiste dans l'idée que ce n'est pas une bonne solution
d'installer son Application dans la racine du disque.
>Jean-marc wrote:
>Jean-marc wrote:
>Jean-marc wrote:
Vous vous permettez de me tutoyer mais, comme vous aviez eu la gentillesse
de me répondre avec pertinence à d'autres questions que j'avais posées, je
ne vous en tenais pas rigueur, même si vous avez vraisemblablement l'âge de
mes petits-fils.
Mais voilà que maintenant vous ironisez grossièrement et stupidement.
Rafale est un logiciel de publipostage que j'ai développé quand Vista
n'existait pas encore et qui peut être utilisé ou bien, par exemple, par le
paisible retraité, président d'une association -- comme c'est mon cas --
pour transmettre des informations aux adhérents de cette association, ou
bien par un spammeur, ce dont je ne saurais être tenu responsable (comme les
concepteurs d'une Mercedes ou d'une Peugeot ne sont pas tenus responsables
des excès de vitesse commis par les conducteurs de leurs automobiles).
Un utilisateur ancien et fidèle de ce logiciel Rafale m'a demandé de
l'adapter afin qu'il puisse fonctionner sur son nouvel ordinateur sous
Vista. Je croyais y être parvenu jusqu'au moment où j'ai demandé à cet
utilisateur de tester la désinstallation : le programme de désinstallation
ne trouve pas le fichier Uninstal.log créé par l'application dans son
répertoire parce que ce répertoire est un sous-répertoire de 'Program
Files'.
Tout se passe donc comme si, pour des raisons que j'ignore (seriez-vous
actionnaire chez Microsoft ?),
solution pour empêcher l'utilisateur d'installer Rafale ou toute autre
application devant être utilisée sous Vista en contournant les emmerderies
créées par la nouvelle gestion invraisemblable sous Vista de 'Program Files'
qui interdit pratiquement toute écriture de données dans un sous-répertoire
de l'application quand cette application est installée dans 'Program Files'.
Mais la plupart des applications existantes écrivent leurs données dans des
sous-répertoires de cette application et Vista rique fort de poser bien des
problèmes aux utilisateurs de tous ces logiciels.
Tant pis si je ne découvre pas cette solution. Il me suffira de demander à
l'utilisateur d'installer l'application « sur le disque où se trouve Windows
dans le répertoire nommé par exemple 'KiriasseMonAppli' » puis, dans
l'appli elle-même, de vérifier dès son ouverture que le répertoire de
l'application est bien celui-là et de fermer cette appli dans le cas
contraire avec un MsgBox du genre :
MsgBox "Vous n'avez pas installé MonAppli dans le bon répertoire." & vbcrlf
& _
"Veuillez réinstaller MonAppli comme cela vous a été demandé par le
programme d'installation.", 16, "Fin du programme"
J'aurais ainsi épargné à cet utilisateur bien des désagréments et
tracasseries.
Quand je parle d'emmerderie, de désagréments, de tracasseries, est-ce que
j'exagère ?
Ces consignes me paraissent à l'évidence bien dissuasives pour la plupart
des utilisateurs de logiciels qui ont été développés à une époque où Vista
n'existait pas. Sans parler des fichiers HLP qui ne fonctionnent plus sans
une mise à jour à installer depuis le site de Microsoft. Ou encore du
contrôle dhtmled.ocx qui ne fonctionne plus sous Vista sans une mise à jour
à aller chercher au diable sur le même site. Pour n'évoquer que ce que j'ai
pu déjà découvrir avant même d'avoir installé Vista sur mon propre
ordinateur...
Vous vous permettez de me tutoyer mais, comme vous aviez eu la gentillesse
de me répondre avec pertinence à d'autres questions que j'avais posées, je
ne vous en tenais pas rigueur, même si vous avez vraisemblablement l'âge de
mes petits-fils.
Mais voilà que maintenant vous ironisez grossièrement et stupidement.
Rafale est un logiciel de publipostage que j'ai développé quand Vista
n'existait pas encore et qui peut être utilisé ou bien, par exemple, par le
paisible retraité, président d'une association -- comme c'est mon cas --
pour transmettre des informations aux adhérents de cette association, ou
bien par un spammeur, ce dont je ne saurais être tenu responsable (comme les
concepteurs d'une Mercedes ou d'une Peugeot ne sont pas tenus responsables
des excès de vitesse commis par les conducteurs de leurs automobiles).
Un utilisateur ancien et fidèle de ce logiciel Rafale m'a demandé de
l'adapter afin qu'il puisse fonctionner sur son nouvel ordinateur sous
Vista. Je croyais y être parvenu jusqu'au moment où j'ai demandé à cet
utilisateur de tester la désinstallation : le programme de désinstallation
ne trouve pas le fichier Uninstal.log créé par l'application dans son
répertoire parce que ce répertoire est un sous-répertoire de 'Program
Files'.
Tout se passe donc comme si, pour des raisons que j'ignore (seriez-vous
actionnaire chez Microsoft ?),
solution pour empêcher l'utilisateur d'installer Rafale ou toute autre
application devant être utilisée sous Vista en contournant les emmerderies
créées par la nouvelle gestion invraisemblable sous Vista de 'Program Files'
qui interdit pratiquement toute écriture de données dans un sous-répertoire
de l'application quand cette application est installée dans 'Program Files'.
Mais la plupart des applications existantes écrivent leurs données dans des
sous-répertoires de cette application et Vista rique fort de poser bien des
problèmes aux utilisateurs de tous ces logiciels.
Tant pis si je ne découvre pas cette solution. Il me suffira de demander à
l'utilisateur d'installer l'application « sur le disque où se trouve Windows
dans le répertoire nommé par exemple 'KiriasseMonAppli' » puis, dans
l'appli elle-même, de vérifier dès son ouverture que le répertoire de
l'application est bien celui-là et de fermer cette appli dans le cas
contraire avec un MsgBox du genre :
MsgBox "Vous n'avez pas installé MonAppli dans le bon répertoire." & vbcrlf
& _
"Veuillez réinstaller MonAppli comme cela vous a été demandé par le
programme d'installation.", 16, "Fin du programme"
J'aurais ainsi épargné à cet utilisateur bien des désagréments et
tracasseries.
Quand je parle d'emmerderie, de désagréments, de tracasseries, est-ce que
j'exagère ?
Ces consignes me paraissent à l'évidence bien dissuasives pour la plupart
des utilisateurs de logiciels qui ont été développés à une époque où Vista
n'existait pas. Sans parler des fichiers HLP qui ne fonctionnent plus sans
une mise à jour à installer depuis le site de Microsoft. Ou encore du
contrôle dhtmled.ocx qui ne fonctionne plus sous Vista sans une mise à jour
à aller chercher au diable sur le même site. Pour n'évoquer que ce que j'ai
pu déjà découvrir avant même d'avoir installé Vista sur mon propre
ordinateur...
Vous vous permettez de me tutoyer mais, comme vous aviez eu la gentillesse
de me répondre avec pertinence à d'autres questions que j'avais posées, je
ne vous en tenais pas rigueur, même si vous avez vraisemblablement l'âge de
mes petits-fils.
Mais voilà que maintenant vous ironisez grossièrement et stupidement.
Rafale est un logiciel de publipostage que j'ai développé quand Vista
n'existait pas encore et qui peut être utilisé ou bien, par exemple, par le
paisible retraité, président d'une association -- comme c'est mon cas --
pour transmettre des informations aux adhérents de cette association, ou
bien par un spammeur, ce dont je ne saurais être tenu responsable (comme les
concepteurs d'une Mercedes ou d'une Peugeot ne sont pas tenus responsables
des excès de vitesse commis par les conducteurs de leurs automobiles).
Un utilisateur ancien et fidèle de ce logiciel Rafale m'a demandé de
l'adapter afin qu'il puisse fonctionner sur son nouvel ordinateur sous
Vista. Je croyais y être parvenu jusqu'au moment où j'ai demandé à cet
utilisateur de tester la désinstallation : le programme de désinstallation
ne trouve pas le fichier Uninstal.log créé par l'application dans son
répertoire parce que ce répertoire est un sous-répertoire de 'Program
Files'.
Tout se passe donc comme si, pour des raisons que j'ignore (seriez-vous
actionnaire chez Microsoft ?),
solution pour empêcher l'utilisateur d'installer Rafale ou toute autre
application devant être utilisée sous Vista en contournant les emmerderies
créées par la nouvelle gestion invraisemblable sous Vista de 'Program Files'
qui interdit pratiquement toute écriture de données dans un sous-répertoire
de l'application quand cette application est installée dans 'Program Files'.
Mais la plupart des applications existantes écrivent leurs données dans des
sous-répertoires de cette application et Vista rique fort de poser bien des
problèmes aux utilisateurs de tous ces logiciels.
Tant pis si je ne découvre pas cette solution. Il me suffira de demander à
l'utilisateur d'installer l'application « sur le disque où se trouve Windows
dans le répertoire nommé par exemple 'KiriasseMonAppli' » puis, dans
l'appli elle-même, de vérifier dès son ouverture que le répertoire de
l'application est bien celui-là et de fermer cette appli dans le cas
contraire avec un MsgBox du genre :
MsgBox "Vous n'avez pas installé MonAppli dans le bon répertoire." & vbcrlf
& _
"Veuillez réinstaller MonAppli comme cela vous a été demandé par le
programme d'installation.", 16, "Fin du programme"
J'aurais ainsi épargné à cet utilisateur bien des désagréments et
tracasseries.
Quand je parle d'emmerderie, de désagréments, de tracasseries, est-ce que
j'exagère ?
Ces consignes me paraissent à l'évidence bien dissuasives pour la plupart
des utilisateurs de logiciels qui ont été développés à une époque où Vista
n'existait pas. Sans parler des fichiers HLP qui ne fonctionnent plus sans
une mise à jour à installer depuis le site de Microsoft. Ou encore du
contrôle dhtmled.ocx qui ne fonctionne plus sous Vista sans une mise à jour
à aller chercher au diable sur le même site. Pour n'évoquer que ce que j'ai
pu déjà découvrir avant même d'avoir installé Vista sur mon propre
ordinateur...
Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Bonjour jean-marc,
Jean-marc a écrit :Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Peut être récupérer l'unité de disque dans la clé :
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir
Bonjour jean-marc,
Jean-marc a écrit :
Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Peut être récupérer l'unité de disque dans la clé :
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir
Bonjour jean-marc,
Jean-marc a écrit :Jean-marc wrote:
Arf !!!
Posté trop vite :-(
Tel quel l'exe retourne pour (root) la lettre du
premier lectuer fixe, donc toujours C:
Il ne fait donc pas faire:
Case UCase$(gstrWINDRIVE$)
strResolved = strRootDrive()
mais un truc du genre récupérer le début de Winpath:
gstrWinSysDir
Bref, c'est l'idée :-)
Peut être récupérer l'unité de disque dans la clé :
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir
Dans : news:475bb3c8$0$29261$,
Jean-marc disait :Fred wrote:Dans : news:475bad1f$0$29264$,N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Dans : news:475bb3c8$0$29261$ba620e4c@news.skynet.be,
Jean-marc disait :
Fred wrote:
Dans : news:475bad1f$0$29264$ba620e4c@news.skynet.be,
N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Dans : news:475bb3c8$0$29261$,
Jean-marc disait :Fred wrote:Dans : news:475bad1f$0$29264$,N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Fred a écrit :Dans : news:475bb3c8$0$29261$,
Jean-marc disait :Fred wrote:Dans : news:475bad1f$0$29264$,N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Non c'est le fichier setup.lst qui donne l'ensemble des actions faites
par le setup.exe. En fait, d'après ce que j'ai compris, le setup.exe lis
le setup.lst pour savoir ce qu'il doit faire, comme inno-setup
d'ailleurs qui peut récupérer setup.lst pour créer un fichier
d'installation.
Fred a écrit :
Dans : news:475bb3c8$0$29261$ba620e4c@news.skynet.be,
Jean-marc disait :
Fred wrote:
Dans : news:475bad1f$0$29264$ba620e4c@news.skynet.be,
N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Non c'est le fichier setup.lst qui donne l'ensemble des actions faites
par le setup.exe. En fait, d'après ce que j'ai compris, le setup.exe lis
le setup.lst pour savoir ce qu'il doit faire, comme inno-setup
d'ailleurs qui peut récupérer setup.lst pour créer un fichier
d'installation.
Fred a écrit :Dans : news:475bb3c8$0$29261$,
Jean-marc disait :Fred wrote:Dans : news:475bad1f$0$29264$,N'y a -t-il pas les sources du setup quelque part ? Je crois me
souvenir que oui.
Je ne sais pas, j'avoue que ça ne me dit rien. C'est très
possible en tout cas, mais j'ignore ou on peut trouver
ça.
De mémoire : dans le répertoire d'installation de VB, un setup.bas
peut-être (?)
C'est juste pour l'amusement de créer une macro supplémentaire ;-)
Non c'est le fichier setup.lst qui donne l'ensemble des actions faites
par le setup.exe. En fait, d'après ce que j'ai compris, le setup.exe lis
le setup.lst pour savoir ce qu'il doit faire, comme inno-setup
d'ailleurs qui peut récupérer setup.lst pour créer un fichier
d'installation.