Discussion :

[_Michel]

Bonjour,
Pour qu'un programme dispose d'un paramétrage (taille de la fenêtre principale, etc, etc), on peut placer un fichier de configuration dans le dossier de l'executable, par exemple, ou alors farcir la base de registre, mais pour faire vraiment propre, il n'y a pas moyen d'incorporer les données dans l'executable lui-même ?

Avec les ressources, on peut placer des données dans l'executable, mais avec FindResource, LoadResource et LockResource, on ne peut avoir qu'un pointeur sur une copie de l'information. On ne peut pas modifier ces données.
Y a-t-il une solution autre que cet affreux bidouillage :
- créer une ressource de n octets qui commence par une balise de 4 octets par exemple
- lors de l'execution du programme, ouvrir l'executable en écriture et rechercher cette balise
- placer un pointeur fichier sur cette balise, qui indique le début de la mémoire allouée aux données
?

Merci d'avance pour votre aide.

[Médinoc]

Ben non, l'exécutable est censé être en lecture seule pendant l'exécution...

Le plus proche de ça qui reste humainement possible, c'est ce que faisaient certains Message Mates quand on les personnalisait: Créer une copie de l'exécutable et modifier les ressources de la copie (BeginUpdateResource() etc.)

[droggo]

Fio,

Bonjour,
Pour qu'un programme dispose d'un paramétrage (taille de la fenêtre principale, etc, etc), on peut placer un fichier de configuration dans le dossier de l'executable, par exemple, ou alors farcir la base de registre, mais pour faire vraiment propre, il n'y a pas moyen d'incorporer les données dans l'executable lui-même ?...

Pour "faire vraiment propre", tu viens d'énoncer les manières d'opérer. Ce que tu cherches à faire est du bidouillage.

[Médinoc]

Pour "faire vraiment propre", tu viens d'énoncer les manières d'opérer. Ce que tu cherches à faire est du bidouillage.

+1

[ram-0000]

4 points différents pour te montrer que cette approche n'est pas très saine :

1/ Un binaire peut être placé dans un répertoire dont les droits d'accès en écriture sont restreints.

2/ De plus, si ce binaire est placé sur différentes machines et exécuté de différentes manières avec des configurations différentes, les binaires sur ces 2 machines seront différents alors qu'ils font strictement la même chose.

3/ Si tu fais une mise à jour de ton binaire avec une nouvelle version, tu vas perdre la configuration des utilisateurs enregistrée dans le binaire.

4/ Comment est-ce que tu peux gérer sur une machine, une configuration différente par utilisateur.

Je pense donc comme les autres que c'est une solution "boiteuse" et pas viable.

[_Michel]

Je peut même rajouter deux points : si le programme est executé plusieurs fois en même temps, il peut y avoir marchage sur pieds, et si jamais la balise correspond à du code, ça fous tout par terre (même si ça se vois assez vite si c'est le cas).
C'était juste pour donner un exemple.

Donc, un fichier de configuration, demeure la solution la moins compliquée, mais connait un de ces désavantage : avec des droits d'accès restreints, la personnalisation n'est pas possible.
La différence, c'est que l'utilisateru est au courant de ce qui se passe.

[Médinoc]

Tu sais, tu peux toujours mettre le fichier de configuration dans le dossier Application Data de l'utilisateur... (voir SHGetFolderPath() et CSIDL_APPDATA).

Ou bien, tout simplement dans la base de registre, section Utilisateur. De toutes façon, dans les deux cas, les données ne seront pas "immédiatement visibles" à côté de l'exécutable...