Dans , http://faq.vb.free.fr/index.php?question=113, vous écrivez :
<Mais attention à la performance ! Car avec cette méthode, vous risquez de
parcourir inutilement de nombreuses fois le fichier. En effet, dans votre
programme, vous allez parcourir tous vos contrôles, et pour chacun d'eux
vous allez parcourir le fichier texte jusqu'à trouver le chaîne
correspondante.>
Tout à fait d'accord parcequ'on a mis les chaînes à chercher dans un simple
fichier texte.
Aussi vous conseillez la structure des fichiers ini à lire par
GetPrivateProfileString. Les clés de recherche y seront :
- Le nom du fichier consacré à la langue, par ex. "french.lng".
- Le nom de la feuille en cours, ex. "frmMain".
- Le nom du contrôle concerné, ex. "lblToto".
Puis vous présentez la solution des fichiers ressources avec DLL satellites.
Et vous terminez en déclarant :
<Une dernière solution à mentionner, car elle revient souvent sur les
forums, est l'emploi d'une base de données pour stocker les chaînes de
caractères. Mais il s'agit d'une très mauvaise solution, très lente, très
peu performante et totalement inadaptée. Comme dirait certains, c'est comme
employer un missile sol-air pour abattre un lapin.>
Rangez-vous dans cette catégorie la solution que j'utilise :
Chaque chaîne à afficher est la valeur de l'une de mes fonctions etiX() ou
msgX() qui sont contenues dans mon module laïus.bas et qui sont de la forme
:
Public Function eti2(la%, Indx%) As String
' Exemple pour 2 langues : Français la = 0, Anglais la = 1
If la = 0 Then
Select Case Indx
Case 0: eti2 = "Sélectionner"
' etc...
End Select
Else
Select Case Indx
Case 0: eti2 = "Select"
' etc...
End Select
End If
End Function
Lorsque l'utilisateur demande sa langue, il fixe "la" (variable globale).
Quand je crée mes menus, contrôles, messages ...il me suffit de leur
affecter le X du nom de la fonction (Ex. 2 pour eti2) et leur Indx dans
celle-ci. Par exemple j'écris :
ret = MsgBox(msg0(la, 72) & W4 & msg0(la, 73), 36)
If ret = 6 Then
' ...
Il ne me semble pas que cette méthode, qui a l'avantage de la simplicité,
soit lente et lourde. Le pensez-vous ?
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
Pierre Alexis
Salut Yves,
La solution que tu as décrites n'est certes pas lentes du tout. Elle est même très rapide. Puisque en interne, tous ce que le processeur fait, c'est des comparaison entière et des jumps...
Là où le bas blesse je dirais c'est qu'il est très vivement recommander d'éviter de hard-coder les strings dans le code. Pour la simple raison que si tu changes un string, tu dois recompiler tout le programme ou du moins tout le module. Tandis que si tu emplois un fichier ressource, il te suffit de recompiler ce fichier et de le linker au programme. Je suis d'accord que cette remarque s'applique plus au C++, car en VB il n'y a pas moyen de compiler indépendemment différents modules. Et compiler un module de ressource prend beaucoup moins de temps que de compiler un module de code... Autre chose, les ressources peuvent être éditées par un éditeur de ressource après que le programme ait été compilé et linké. Du fait de cette indépendance entre le programme et les ressources, la répartition du travail s'en voit facilitée dans le cas où une personne travaille sur le code et une autre sur les ressources. De plus, (pas en VB, je sais), les ressources permettent de gérer plusieurs langues de manière plus ou moins simple. Aussi, les ressources sont totalement indépendantes du language de pogrammation employé. Ainsi un simple traducteur pourra travailler facilement à ton fichier ressource sans avoir à connaître VB ou le C++. Autre remarque qui me vient à l'esprit, les ressources sont gérées par l'OS. Et sont donc gérées de manières beaucoup plus appropriées que si tu hard-code tes strings. Par exemple, ton module lui sera d'office chargé en mémoire car l'OS ne sait pas qu'en fait c'est une fonction gérant les ressources. Tandis que lorsque tu utilises un fichier ressource, l'OS sait qu'il s'agit de ressource et sait donc les gérer au mieux.
La solution que tu as décrites n'est certes pas lentes du tout. Elle est même
très rapide. Puisque en interne, tous ce que le processeur fait, c'est des
comparaison entière et des jumps...
Là où le bas blesse je dirais c'est qu'il est très vivement recommander
d'éviter de hard-coder les strings dans le code. Pour la simple raison que si
tu changes un string, tu dois recompiler tout le programme ou du moins tout le
module. Tandis que si tu emplois un fichier ressource, il te suffit de
recompiler ce fichier et de le linker au programme. Je suis d'accord que cette
remarque s'applique plus au C++, car en VB il n'y a pas moyen de compiler
indépendemment différents modules. Et compiler un module de ressource prend
beaucoup moins de temps que de compiler un module de code...
Autre chose, les ressources peuvent être éditées par un éditeur de ressource
après que le programme ait été compilé et linké. Du fait de cette indépendance
entre le programme et les ressources, la répartition du travail s'en voit
facilitée dans le cas où une personne travaille sur le code et une autre sur
les ressources. De plus, (pas en VB, je sais), les ressources permettent de
gérer plusieurs langues de manière plus ou moins simple. Aussi, les ressources
sont totalement indépendantes du language de pogrammation employé. Ainsi un
simple traducteur pourra travailler facilement à ton fichier ressource sans
avoir à connaître VB ou le C++.
Autre remarque qui me vient à l'esprit, les ressources sont gérées par l'OS.
Et sont donc gérées de manières beaucoup plus appropriées que si tu hard-code
tes strings. Par exemple, ton module lui sera d'office chargé en mémoire car
l'OS ne sait pas qu'en fait c'est une fonction gérant les ressources. Tandis
que lorsque tu utilises un fichier ressource, l'OS sait qu'il s'agit de
ressource et sait donc les gérer au mieux.
La solution que tu as décrites n'est certes pas lentes du tout. Elle est même très rapide. Puisque en interne, tous ce que le processeur fait, c'est des comparaison entière et des jumps...
Là où le bas blesse je dirais c'est qu'il est très vivement recommander d'éviter de hard-coder les strings dans le code. Pour la simple raison que si tu changes un string, tu dois recompiler tout le programme ou du moins tout le module. Tandis que si tu emplois un fichier ressource, il te suffit de recompiler ce fichier et de le linker au programme. Je suis d'accord que cette remarque s'applique plus au C++, car en VB il n'y a pas moyen de compiler indépendemment différents modules. Et compiler un module de ressource prend beaucoup moins de temps que de compiler un module de code... Autre chose, les ressources peuvent être éditées par un éditeur de ressource après que le programme ait été compilé et linké. Du fait de cette indépendance entre le programme et les ressources, la répartition du travail s'en voit facilitée dans le cas où une personne travaille sur le code et une autre sur les ressources. De plus, (pas en VB, je sais), les ressources permettent de gérer plusieurs langues de manière plus ou moins simple. Aussi, les ressources sont totalement indépendantes du language de pogrammation employé. Ainsi un simple traducteur pourra travailler facilement à ton fichier ressource sans avoir à connaître VB ou le C++. Autre remarque qui me vient à l'esprit, les ressources sont gérées par l'OS. Et sont donc gérées de manières beaucoup plus appropriées que si tu hard-code tes strings. Par exemple, ton module lui sera d'office chargé en mémoire car l'OS ne sait pas qu'en fait c'est une fonction gérant les ressources. Tandis que lorsque tu utilises un fichier ressource, l'OS sait qu'il s'agit de ressource et sait donc les gérer au mieux.
