Localisation système VB pour appli multilingue : quelle stratégie ?
10 réponses
Us
Bonjour à tous,
Petit problème de conscience. Voilà, j'ai une application écrite en VB6.
Dans celle-ci, l'utilisateur peut choisir sa langue entre français et
anglais. Ceci ayant pour effet de traduire l'interface et les différents
messages propres au programme.
Avec cette application, je livre et installe les 6 fichiers du runtime
VB6 et comdlg32.ocx qui est le seul OCX utile à mon appli.
Par contre, que faire des "localizations" de ces éléments système VB6 :
soit, VB6FR.DLL et CMDLGFR.DLL ?
A priori, si je ne les livre pas, la partie système de mon appli
(messages d'erreur VB et boîte parcourir) sera en anglais, même si
l'utilisateur choisi le français dans l'appli elle-même.
Et si je les livre, tout sera en français, mais si l'utilisateur choisi
l'anglais dans l'appli, il sera étonné de trouver la partie système
(messages d'erreur et boîte parcourir toujours) en français.
Comment faire ? Est-ce que quelqu'un a une expérience d'une appli
multilingue (bilingue ici) avec changement de langue à la volé (c-à-d
que le choix ne se fait pas à l'install, mais à la volée durant
l'utilisation du logiciel, via un menu et à tout moment).
Faut-il que j'enregistre les deux fichiers français (via regsrv32) à la
volée quand l'utilisateur choisi le français et les désenregistre s'il
bascule vers l'anglais ?
Il y a un truc qui n'est pas clair dans mon esprit sur ce sujet ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-marc
Us wrote:
Bonjour à tous,
Petit problème de conscience. Voilà, j'ai une application écrite en VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre français et anglais. Ceci ayant pour effet de traduire l'interface et les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Ainsi, il est courant d'avoir une appli installée en anglais mais avec les boites de dialogues système dans la langue d'installation de l'OS (français chez moi). Et inversement au boulot, mon OS est en anglais, et j'ai 2 ou 3 applis avec menus en français mais bien sur les boites de dialogie genre "Open file" sont en Anglais.
C'est en tout cas mon expérience, certains ont peut etre une vue différente sur le sujet.
Une chose est sure, je déteste (et je ne suis pas le seul) les applis qui se permettent de changer mes Dll système, avec tous les riques et problèmes que ça entraine 99 fois sur 100.
(Que celui qui n'a jamais passé des heures à trouver pourquoi une appli qui tournait à la perfection depuis des années refuse soudainement de se lancer avec un message d'erreur exotique suite à l'installation d'un soft m*ique qui a cru bon de remplacer les éléments système par des versions étrangères ou out-datées me jette la première pierre...)
Petit problème de conscience. Voilà, j'ai une application écrite en
VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre
français et anglais. Ceci ayant pour effet de traduire l'interface et
les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse
tranquille les éléments système (notamment vb6xx.dll!!).
Ainsi, il est courant d'avoir une appli installée en anglais mais
avec les boites de dialogues système dans la langue d'installation
de l'OS (français chez moi). Et inversement au boulot, mon OS est
en anglais, et j'ai 2 ou 3 applis avec menus en français mais bien
sur les boites de dialogie genre "Open file" sont en Anglais.
C'est en tout cas mon expérience, certains ont peut etre une vue
différente sur le sujet.
Une chose est sure, je déteste (et je ne suis pas le seul) les applis
qui se permettent de changer mes Dll système, avec tous les riques
et problèmes que ça entraine 99 fois sur 100.
(Que celui qui n'a jamais passé des heures à trouver pourquoi une
appli qui tournait à la perfection depuis des années refuse soudainement
de se lancer avec un message d'erreur exotique suite à l'installation
d'un soft m*ique qui a cru bon de remplacer les éléments système par
des versions étrangères ou out-datées me jette la première pierre...)
Petit problème de conscience. Voilà, j'ai une application écrite en VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre français et anglais. Ceci ayant pour effet de traduire l'interface et les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Ainsi, il est courant d'avoir une appli installée en anglais mais avec les boites de dialogues système dans la langue d'installation de l'OS (français chez moi). Et inversement au boulot, mon OS est en anglais, et j'ai 2 ou 3 applis avec menus en français mais bien sur les boites de dialogie genre "Open file" sont en Anglais.
C'est en tout cas mon expérience, certains ont peut etre une vue différente sur le sujet.
Une chose est sure, je déteste (et je ne suis pas le seul) les applis qui se permettent de changer mes Dll système, avec tous les riques et problèmes que ça entraine 99 fois sur 100.
(Que celui qui n'a jamais passé des heures à trouver pourquoi une appli qui tournait à la perfection depuis des années refuse soudainement de se lancer avec un message d'erreur exotique suite à l'installation d'un soft m*ique qui a cru bon de remplacer les éléments système par des versions étrangères ou out-datées me jette la première pierre...)
Us wrote: > Bonjour à tous, > > Petit problème de conscience. Voilà, j'ai une application écrite en > VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre > français et anglais. Ceci ayant pour effet de traduire l'interface et > les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon package actuel ne contient que les 6 fichiers de runtime VB6 SP6 en anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
In article <47370c01$0$29265$ba620e4c@news.skynet.be>,
NO_SPAM_jean_marc_n2@yahoo.fr.invalid says...
Us wrote:
> Bonjour à tous,
>
> Petit problème de conscience. Voilà, j'ai une application écrite en
> VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre
> français et anglais. Ceci ayant pour effet de traduire l'interface et
> les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse
tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon package
actuel ne contient que les 6 fichiers de runtime VB6 SP6 en anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
Us wrote: > Bonjour à tous, > > Petit problème de conscience. Voilà, j'ai une application écrite en > VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre > français et anglais. Ceci ayant pour effet de traduire l'interface et > les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon package actuel ne contient que les 6 fichiers de runtime VB6 SP6 en anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
Jean-marc
Us wrote:
In article <47370c01$0$29265$, says...
Us wrote:
Bonjour à tous,
Petit problème de conscience. Voilà, j'ai une application écrite en VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre français et anglais. Ceci ayant pour effet de traduire l'interface et les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon package actuel ne contient que les 6 fichiers de runtime VB6 SP6 en anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
In article <47370c01$0$29265$ba620e4c@news.skynet.be>,
NO_SPAM_jean_marc_n2@yahoo.fr.invalid says...
Us wrote:
Bonjour à tous,
Petit problème de conscience. Voilà, j'ai une application écrite en
VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre
français et anglais. Ceci ayant pour effet de traduire l'interface
et les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse
tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon
package actuel ne contient que les 6 fichiers de runtime VB6 SP6 en
anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
Petit problème de conscience. Voilà, j'ai une application écrite en VB6. Dans celle-ci, l'utilisateur peut choisir sa langue entre français et anglais. Ceci ayant pour effet de traduire l'interface et les différents messages propres au programme.
Hello,
En général, on traduit toute la partie applicative, et on laisse tranquille les éléments système (notamment vb6xx.dll!!).
Merci, Jean-Marc. Ce que tu me dis là est ce que j'ai fait ; mon package actuel ne contient que les 6 fichiers de runtime VB6 SP6 en anglais.
Je n'ai donc rien de plus à faire et pas de prise de tête : youpi !
A priori, si je ne les livre pas, la partie système de mon appli (messages d'erreur VB et boîte parcourir) sera en anglais, même si l'utilisateur choisi le français dans l'appli elle-même.
Salut,
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pa s vb6fr.dll l'installation refusait de se faire. Ou bien c'était un message que j'aurais dû ignorer ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles o n risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Us a écrit, le 11/11/2007 13:48 :
A priori, si je ne les livre pas, la partie système de mon appli
(messages d'erreur VB et boîte parcourir) sera en anglais, même si
l'utilisateur choisi le français dans l'appli elle-même.
Salut,
Serait-ce que ma mémoire me jouerait des tours ?
Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pa s
vb6fr.dll l'installation refusait de se faire.
Ou bien c'était un message que j'aurais dû ignorer ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles o n
risque bien moins d'ennuis à les installer dans le répertoire de
l'application que dans celui de Windows -mais là ce n'est plus
tout-à-fait le sujet de la localisation.
A priori, si je ne les livre pas, la partie système de mon appli (messages d'erreur VB et boîte parcourir) sera en anglais, même si l'utilisateur choisi le français dans l'appli elle-même.
Salut,
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pa s vb6fr.dll l'installation refusait de se faire. Ou bien c'était un message que j'aurais dû ignorer ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles o n risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Tous les messages sont enregistrés dans les trois langues (traduction approximative), et j'ai fait en sorte que rien n'apparaisse dans une langue différente de celle choisie, ou alors, de prendre des mots qui ont un sens identique dans les trois langues, comme "tarot" par exemple...
Donc, comme susdit par plusieurs, l'installation se fait en FR, et tout ce qui est lisible est traduit selon demande utilisateur.
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Us" a écrit dans le message de news:
| Bonjour à tous, | | Petit problème de conscience. Voilà, j'ai une application écrite en VB6. | Dans celle-ci, l'utilisateur peut choisir sa langue entre français et | anglais. Ceci ayant pour effet de traduire l'interface et les différents | messages propres au programme. | | Avec cette application, je livre et installe les 6 fichiers du runtime | VB6 et comdlg32.ocx qui est le seul OCX utile à mon appli. | | Par contre, que faire des "localizations" de ces éléments système VB6 : | soit, VB6FR.DLL et CMDLGFR.DLL ? | | A priori, si je ne les livre pas, la partie système de mon appli | (messages d'erreur VB et boîte parcourir) sera en anglais, même si | l'utilisateur choisi le français dans l'appli elle-même. | | Et si je les livre, tout sera en français, mais si l'utilisateur choisi | l'anglais dans l'appli, il sera étonné de trouver la partie système | (messages d'erreur et boîte parcourir toujours) en français. | | Comment faire ? Est-ce que quelqu'un a une expérience d'une appli | multilingue (bilingue ici) avec changement de langue à la volé (c-à-d | que le choix ne se fait pas à l'install, mais à la volée durant | l'utilisation du logiciel, via un menu et à tout moment). | | Faut-il que j'enregistre les deux fichiers français (via regsrv32) à la | volée quand l'utilisateur choisi le français et les désenregistre s'il | bascule vers l'anglais ? | | Il y a un truc qui n'est pas clair dans mon esprit sur ce sujet ;)
Tous les messages sont enregistrés dans les
trois langues (traduction approximative), et j'ai
fait en sorte que rien n'apparaisse dans une
langue différente de celle choisie, ou alors, de
prendre des mots qui ont un sens identique dans
les trois langues, comme "tarot" par exemple...
Donc, comme susdit par plusieurs,
l'installation se fait en FR, et tout ce qui est
lisible est traduit selon demande utilisateur.
--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Us" <none@invalid.org> a écrit dans le message de
news:
MPG.21a118775e0fe25798996b@news.tiscali.fr...
| Bonjour à tous,
|
| Petit problème de conscience. Voilà, j'ai une
application écrite en VB6.
| Dans celle-ci, l'utilisateur peut choisir sa
langue entre français et
| anglais. Ceci ayant pour effet de traduire
l'interface et les différents
| messages propres au programme.
|
| Avec cette application, je livre et installe les
6 fichiers du runtime
| VB6 et comdlg32.ocx qui est le seul OCX utile à
mon appli.
|
| Par contre, que faire des "localizations" de ces
éléments système VB6 :
| soit, VB6FR.DLL et CMDLGFR.DLL ?
|
| A priori, si je ne les livre pas, la partie
système de mon appli
| (messages d'erreur VB et boîte parcourir) sera
en anglais, même si
| l'utilisateur choisi le français dans l'appli
elle-même.
|
| Et si je les livre, tout sera en français, mais
si l'utilisateur choisi
| l'anglais dans l'appli, il sera étonné de
trouver la partie système
| (messages d'erreur et boîte parcourir toujours)
en français.
|
| Comment faire ? Est-ce que quelqu'un a une
expérience d'une appli
| multilingue (bilingue ici) avec changement de
langue à la volé (c-à-d
| que le choix ne se fait pas à l'install, mais à
la volée durant
| l'utilisation du logiciel, via un menu et à tout
moment).
|
| Faut-il que j'enregistre les deux fichiers
français (via regsrv32) à la
| volée quand l'utilisateur choisi le français et
les désenregistre s'il
| bascule vers l'anglais ?
|
| Il y a un truc qui n'est pas clair dans mon
esprit sur ce sujet ;)
Tous les messages sont enregistrés dans les trois langues (traduction approximative), et j'ai fait en sorte que rien n'apparaisse dans une langue différente de celle choisie, ou alors, de prendre des mots qui ont un sens identique dans les trois langues, comme "tarot" par exemple...
Donc, comme susdit par plusieurs, l'installation se fait en FR, et tout ce qui est lisible est traduit selon demande utilisateur.
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Us" a écrit dans le message de news:
| Bonjour à tous, | | Petit problème de conscience. Voilà, j'ai une application écrite en VB6. | Dans celle-ci, l'utilisateur peut choisir sa langue entre français et | anglais. Ceci ayant pour effet de traduire l'interface et les différents | messages propres au programme. | | Avec cette application, je livre et installe les 6 fichiers du runtime | VB6 et comdlg32.ocx qui est le seul OCX utile à mon appli. | | Par contre, que faire des "localizations" de ces éléments système VB6 : | soit, VB6FR.DLL et CMDLGFR.DLL ? | | A priori, si je ne les livre pas, la partie système de mon appli | (messages d'erreur VB et boîte parcourir) sera en anglais, même si | l'utilisateur choisi le français dans l'appli elle-même. | | Et si je les livre, tout sera en français, mais si l'utilisateur choisi | l'anglais dans l'appli, il sera étonné de trouver la partie système | (messages d'erreur et boîte parcourir toujours) en français. | | Comment faire ? Est-ce que quelqu'un a une expérience d'une appli | multilingue (bilingue ici) avec changement de langue à la volé (c-à-d | que le choix ne se fait pas à l'install, mais à la volée durant | l'utilisation du logiciel, via un menu et à tout moment). | | Faut-il que j'enregistre les deux fichiers français (via regsrv32) à la | volée quand l'utilisateur choisi le français et les désenregistre s'il | bascule vers l'anglais ? | | Il y a un truc qui n'est pas clair dans mon esprit sur ce sujet ;)
Us
In article <#, says...
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que tu lui demandes de faire et si tu obtiens un message d'erreur à cette étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Moi, pour le process, j'utilise les fichiers VB venant d'ici : http://www.jrsoftware.org/download.php/vb6sp6sys.zip (et non ceux de mon propre système qui peut-être pourraient être de version et/ou édition différente), selon la procédure décrite ici D:ELNProjNETFFhLabDev EB2MWFLannexeInno Setup Knowledge Base - How to install VB6 appli.htm
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
In article <#WZhlxHJIHA.5468@TK2MSFTNGP05.phx.gbl>, gloops@niark.invalid
says...
Serait-ce que ma mémoire me jouerait des tours ?
Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas
vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que
tu lui demandes de faire et si tu obtiens un message d'erreur à cette
étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci
est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Moi, pour le process, j'utilise les fichiers VB venant d'ici :
http://www.jrsoftware.org/download.php/vb6sp6sys.zip (et non ceux de mon
propre système qui peut-être pourraient être de version et/ou édition
différente), selon la procédure décrite ici D:ELNProjNETFFhLabDev
EB2MWFLannexeInno Setup Knowledge Base - How to install VB6 appli.htm
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller
chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on
risque bien moins d'ennuis à les installer dans le répertoire de
l'application que dans celui de Windows -mais là ce n'est plus
tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL
communes et connues. Par contre, c'est pour ça que je pense fermement
qu'il ne faut jamais utiliser les DLL provenant de sa plateform de
développement : on y fait tellement de choses qu'on ne sait jamais ;)
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que tu lui demandes de faire et si tu obtiens un message d'erreur à cette étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Moi, pour le process, j'utilise les fichiers VB venant d'ici : http://www.jrsoftware.org/download.php/vb6sp6sys.zip (et non ceux de mon propre système qui peut-être pourraient être de version et/ou édition différente), selon la procédure décrite ici D:ELNProjNETFFhLabDev EB2MWFLannexeInno Setup Knowledge Base - How to install VB6 appli.htm
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
Us
In article , "LE TROLL" <le says...
J'ai fait un jeu de tarot à 4 en "3" langues...
Super, mais la question est pour la partie système. Quand l'utilisateur change de langue par ton menu "Paramètres", est-ce que tui change quelque chose au niveau des fichiers systèmes VB (DLL et OCX) ?
In article <OoHv6NIJIHA.3916@TK2MSFTNGP02.phx.gbl>, "LE TROLL" <le
troll@enfer.fr> says...
J'ai fait un jeu de tarot à 4 en "3"
langues...
Super, mais la question est pour la partie système. Quand l'utilisateur
change de langue par ton menu "Paramètres", est-ce que tui change
quelque chose au niveau des fichiers systèmes VB (DLL et OCX) ?
Super, mais la question est pour la partie système. Quand l'utilisateur change de langue par ton menu "Paramètres", est-ce que tui change quelque chose au niveau des fichiers systèmes VB (DLL et OCX) ?
Us
In article <#, says...
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que tu lui demandes de faire et si tu obtiens un message d'erreur à cette étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
In article <#WZhlxHJIHA.5468@TK2MSFTNGP05.phx.gbl>, gloops@niark.invalid
says...
Serait-ce que ma mémoire me jouerait des tours ?
Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas
vb6fr.dll l'installation refusait de se faire.
Serait-ce que ma mémoire me jouerait des tours ?
Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas
vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que
tu lui demandes de faire et si tu obtiens un message d'erreur à cette
étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci
est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Moi, pour le process, j'utilise les fichiers VB venant d'ici :
http://www.jrsoftware.org/download.php/vb6sp6sys.zip (et non ceux de mon
propre système qui peut-être pourraient être de version et/ou édition
différente), selon la procédure décrite ici
http://www.jrsoftware.org/iskb.php?vb
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller
chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on
risque bien moins d'ennuis à les installer dans le répertoire de
l'application que dans celui de Windows -mais là ce n'est plus
tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL
communes et connues. Par contre, c'est pour ça que je pense fermement
qu'il ne faut jamais utiliser les DLL provenant de sa plateform de
développement : on y fait tellement de choses qu'on ne sait jamais ;)
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Serait-ce que ma mémoire me jouerait des tours ? Il me semble que le jour où j'ai eu à faire ça, si je ne mettais pas vb6fr.dll l'installation refusait de se faire.
Pour l'install, j'utilise Inno. A priori, l'install ne fait que ce que tu lui demandes de faire et si tu obtiens un message d'erreur à cette étape, c'est que quelque chose ne vas pas dans ta procédure... Mais ceci est sans rapport avec le fait que l'appli fonctionne ou pas au final.
Ou bien c'était un message que j'aurais dû ignorer ?
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelles on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
Gloops
Us a écrit, le 11/11/2007 17:56 :
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
Je n'ai pas cherché si loin. Je suis parti du principe que si l'application allait chercher les menus standard dans vb6fr.dll et qu'elle ne l'avait pas, elle ne pourrait pas s'exécuter. Apparemment, j'ai dû me tromper.
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelle s on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
C'est un sujet intéressant à développer. J'ai développé un cert ain nombre de programmes sous VB6, et le jour où j'ai voulu faire tourner ç a sur mon autre machine, rien à faire, ou alors ce sont les autres applications qui se mettent à ne plus fonctionner. Alors tu penses qu'i l vaut mieux aller chercher les DLL courantes ailleurs que chez Microsoft ?=
Us a écrit, le 11/11/2007 17:56 :
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller
chercher pourquoi dans ta propre procédure, non ?
Je n'ai pas cherché si loin.
Je suis parti du principe que si l'application allait chercher les menus
standard dans vb6fr.dll et qu'elle ne l'avait pas, elle ne pourrait pas
s'exécuter. Apparemment, j'ai dû me tromper.
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelle s on
risque bien moins d'ennuis à les installer dans le répertoire de
l'application que dans celui de Windows -mais là ce n'est plus
tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL
communes et connues. Par contre, c'est pour ça que je pense fermement
qu'il ne faut jamais utiliser les DLL provenant de sa plateform de
développement : on y fait tellement de choses qu'on ne sait jamais ;)
C'est un sujet intéressant à développer. J'ai développé un cert ain
nombre de programmes sous VB6, et le jour où j'ai voulu faire tourner ç a
sur mon autre machine, rien à faire, ou alors ce sont les autres
applications qui se mettent à ne plus fonctionner. Alors tu penses qu'i l
vaut mieux aller chercher les DLL courantes ailleurs que chez Microsoft ?=
A priori, c'est toi qui a fait l'install, tu aurais donc dû aller chercher pourquoi dans ta propre procédure, non ?
Je n'ai pas cherché si loin. Je suis parti du principe que si l'application allait chercher les menus standard dans vb6fr.dll et qu'elle ne l'avait pas, elle ne pourrait pas s'exécuter. Apparemment, j'ai dû me tromper.
A part ça il me semble qu'il existe bon nombre de DLL pour lesquelle s on risque bien moins d'ennuis à les installer dans le répertoire de l'application que dans celui de Windows -mais là ce n'est plus tout-à-fait le sujet de la localisation.
Non, mais c'est tout de même la philosophie opposée du principe de DLL communes et connues. Par contre, c'est pour ça que je pense fermement qu'il ne faut jamais utiliser les DLL provenant de sa plateform de développement : on y fait tellement de choses qu'on ne sait jamais ;)
C'est un sujet intéressant à développer. J'ai développé un cert ain nombre de programmes sous VB6, et le jour où j'ai voulu faire tourner ç a sur mon autre machine, rien à faire, ou alors ce sont les autres applications qui se mettent à ne plus fonctionner. Alors tu penses qu'i l vaut mieux aller chercher les DLL courantes ailleurs que chez Microsoft ?=
LE TROLL
Bonsoir,
Ben non, je ne change rien !
En fait, ce serait à changer, si on avait des systèmes d'unités <> par exemple, dans les saisies, mais là, pas besoin pour le tarot, si, au lieu de compter avec le "." pour les anglais, je compte avec la virgule latine, mais bof, et encore, je ne sais même pas si le changement ne se fait pas tout seul, faudrait essayer sur un OS anglais ???
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Us" a écrit dans le message de news:
| In article , "LE TROLL" <le | says... | > J'ai fait un jeu de tarot à 4 en "3" | > langues... | > | | Super, mais la question est pour la partie système. Quand l'utilisateur | change de langue par ton menu "Paramètres", est-ce que tui change | quelque chose au niveau des fichiers systèmes VB (DLL et OCX) ?
Bonsoir,
Ben non, je ne change rien !
En fait, ce serait à changer, si on avait des
systèmes d'unités <> par exemple, dans les
saisies, mais là, pas besoin pour le tarot, si, au
lieu de compter avec le "." pour les anglais, je
compte avec la virgule latine, mais bof, et
encore, je ne sais même pas si le changement ne se
fait pas tout seul, faudrait essayer sur un OS
anglais ???
--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Us" <none@invalid.org> a écrit dans le message de
news:
MPG.21a153825ea9e1fb98996e@news.tiscali.fr...
| In article
<OoHv6NIJIHA.3916@TK2MSFTNGP02.phx.gbl>, "LE
TROLL" <le
| troll@enfer.fr> says...
| > J'ai fait un jeu de tarot à 4 en "3"
| > langues...
| >
|
| Super, mais la question est pour la partie
système. Quand l'utilisateur
| change de langue par ton menu "Paramètres",
est-ce que tui change
| quelque chose au niveau des fichiers systèmes VB
(DLL et OCX) ?
En fait, ce serait à changer, si on avait des systèmes d'unités <> par exemple, dans les saisies, mais là, pas besoin pour le tarot, si, au lieu de compter avec le "." pour les anglais, je compte avec la virgule latine, mais bof, et encore, je ne sais même pas si le changement ne se fait pas tout seul, faudrait essayer sur un OS anglais ???
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Us" a écrit dans le message de news:
| In article , "LE TROLL" <le | says... | > J'ai fait un jeu de tarot à 4 en "3" | > langues... | > | | Super, mais la question est pour la partie système. Quand l'utilisateur | change de langue par ton menu "Paramètres", est-ce que tui change | quelque chose au niveau des fichiers systèmes VB (DLL et OCX) ?