Discussion :

[declencher]

Bonjour,

J'ai commencé à migrer un petit projet perso diffuser gratuitement sur le net pour changer d'EDI : passage de Delphi 7 à Delphi 10.1.

J'ai passé les erreurs de compilation dues aux évolutions du compilateur. Maintenant ça compile.

Le problème suivant apparait au lancement de l'application, lorsqu'elle a besoin d'accéder à son fichier .ini.

Mon appli peut être installée via un installateur (construit avec Innosetup), ou via la décompression d'un zip. Dans le premier cas le fichier ini est déposé dans {commonappdata}\monAppli, commonappdata correspondant à C:\ProgramData\monAppli\monAppli.ini

Dans le 2° cas, le fichier ini est dans le répertoire de l'appli

Au lancement, mon appli test la présence d'un fichier ini dans commonappdata, s'il le trouve il l'utilise. Ou plutôt, je croyais qu'il l'utilisait

En changeant de compilateur, j'ai un plantage lors de la première écriture dans le fichier (impossible d'écrire), alors que la lecture se passe bien. Je debug, et constate que les valeurs lues ne sont pas conformes à ce que j'attendais. Après recherche, voilà ce que j'ai trouvé : mon appli utilise CSIDL_COMMON_APPDATA. Le debuger delphi 7 m'indique bien qu'il s'agit du chemin C:\ProgramData\monAppli\monAppli.ini, et pourtant il ne lit pas la bonne valeur.
Dans les fait, il me créé un fichier à cet emplacement : C:\Users\<account>\AppData\Local\VirtualStore\Program Files\monAppli\monAppli.ini

Le debuger Delphi 10.1 m'indique la même chose (C:\ProgramData\monAppli\monAppli.ini), mais à la différence qu'il utilise réellement ce fichier, et là problème : la lecture du fichier se passe bien, mais l'écriture provoque une exception disant que l'écriture est impossible. Le fichier n'est pas en lecture seule. Par contre je ne peux pas le modifier, même avec Notepad, et je ne comprends pas pourquoi...

Quelqu'un saurait m'expliquer ces comportements et commun coder quelque chose de propre en assurant la compatibilité ascendante pour mes utilisateurs ?

Merci pour votre aide !

[Papy214]

et avec System.IOUtils.TPath ça n'irait pas mieux ?

[declencher]

Je ne le connais pas celui là...

Par contre je suis en train de faire des recherches : certains site recommande CSIDL_COMMON_APPDATA, et la FAQ Delphi ne le cite pas et ne parle que de CSIDL_APPDATA. J'ai testé ce dernier, et là ça m'envoie dans C:\Users\<account>\AppData\Roaming\monAppli...

Edit : j'ai testé mon code avec CSIDL_APPDATA, et là mon appli a les droits de lecture et d'écriture. Si je ne trouve pas plus d'explication je modifierai le script innosetup et je chercherai une solution pour déplacer le fichier de config des utilisateurs lors de l'installation du patch...

[Andnotor]

C'est l'absence de manifest dans les projets D7 qui provoque la redirection vers VirtualStore, le but étant justement d'assurer une compatibilité avec les anciennes applications.

Les Delphi plus récents intègrent ce manifest, il n'y a donc plus de redirection. Par contre, l'UAC limite les possibilités d'écriture sous Program files aux seuls administrateurs.

Il faut revoir le concept de ton application, travailler avec des valeurs par défaut à la place de dézipper l'ini et le créer au besoin (en cas de changement) sous ProgramData (ou AppData).

ProgramData est commun à tous les utilisateurs, AppData est par utilisateur.

[declencher]

Bonjour,

J'en étais arrivé aux mêmes conclusion. Il se trouve que mon appli a déjà un fichier d'installation, et exploit commappdata dans innosetup pour les fichiers de config (et donc le répertoire ProgramData ).

Le problème c'est que ni mon programme compilé avec Delphi 10.1, ni notepad, ne pouvons écrire dans ce fichier :/

[Andnotor]

Le problème c'est que ni mon programme compilé avec Delphi 10.1, ni notepad, ne pouvons écrire dans ce fichier :/

Donne des droits en écriture sur ce répertoire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[Dirs]
Name: {commonappdata}\MonAppli; Permissions: users-modify

[SergioMaster]

Bonjour,

Le debuger Delphi 10.1 m'indique la même chose (C:\ProgramData\monAppli\monAppli.ini), mais à la différence qu'il utilise réellement ce fichier, et là problème : la lecture du fichier se passe bien, mais l'écriture provoque une exception disant que l'écriture est impossible. Le fichier n'est pas en lecture seule. Par contre je ne peux pas le modifier, même avec Notepad, et je ne comprends pas pourquoi...
Quelqu'un saurait m'expliquer ces comportements et commun coder quelque chose de propre en assurant la compatibilité ascendante pour mes utilisateurs ?

la faute à l'UAC (user account control) de Windows Vista et + . Pour modifier avec Notepad il faut lancer Notepad en mode administrateur

et avec System.IOUtils.TPath ça n'irait pas mieux ?

TPath encapsule un certain nombre de méthode pour obtenir les répertoires les plus "communs"
i.e.

	W10
Tpath.GetSharedDocumentsPath	C:\Users\Public\Documents
Tpath.GetDocumentsPath	C:\Users\SergioMaster\Documents
Tpath.GetPublicPath	C:\ProgramData
Tpath.GetHomePath	C:\Users\SergioMaster\AppData\Roaming

mais aussi des méthodes pour combiner des parties de répertoire
i.e TPath.Combine(TPath.Combine(Tpath.GetPublicPath,'monappli'), 'mon.ini');

pour en finir
d'après l'aide CSIDL_COMMON_APPDATA correspond à GetPublicpath
CSIDL_APPDATA GetHomePath