Sélection de police par scripts (sous VB6)
Le
Gloops
Bonjour tout le monde,
Je dois faire sélectionner à mon utilisateur une police de caractèr=
es
parmi celles disponibles dans le script de son pays.
Aussi, j'ai chargé les constantes correspondantes :
Const ansi = 0
Const arabiccharset = 178
Const balticcharset = 186
Const chinesebig5 = 136
Const defaultcharset = 1
Const easteuropecharset = 238
Const easteurope = 238
Je suis parti du projet Enum Fonts trouvé là
http://allapi.mentalis.org/apilist/287C72333936CA5A15A4F5FAA476BD11.html
puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la polic=
e,
afficher son script.
FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)
(et ensuite les mêmes opérations pour s'arrêter au caractère nul)=
Pas de chance, comme résultat, j'ai ça :
Times New Roman : 0 (ansi)
Times New Roman CE : 2 (symbol)
Times New Roman CYR : 2 (symbol)
Times New Roman Greek : 1 (defaultcharacter)
Times New Roman TUR : 1 (defaultcharacter)
Times New Roman Baltic : 1 (defaultcharacter)
En résumé, aucun rapport avec la question.
Pour être bien sûr que nous parlons de la même chose : le nom de la=
police sans rien derrière, correspond au script d'Europe Occidentale.
Avec le suffixe CE, nous avons la même police dans le script d'Europe
Centrale. Avec le suffixe CYR, pour cyrillique, si je me rappelle bien
on s'adresse aux Russes (et on évite soigneusement de proposer ça par=
défaut, par exemple, en Tchéquie). Avec le suffixe TUR, il s'agit du =
script turc. Et Baltic vous devinez.
Je ne mets pas la main sur la sauvegarde de ce que j'ai fait il y a
quelques années, alors il faut que je le refasse. Apparemment, je ne li=
s
pas la valeur au bon endroit, quelqu'un pourrait-il me remettre dans le
droit chemin ?
Aussi bien, peut-être dois-je simplement conserver le suffixe derrièr=
e
le nom de la police ? J'ai bien l'impression que ça va être ça, mai=
s ce
que j'ai recueilli dans FontScript, alors, c'est quoi ?
Je dois faire sélectionner à mon utilisateur une police de caractèr=
es
parmi celles disponibles dans le script de son pays.
Aussi, j'ai chargé les constantes correspondantes :
Const ansi = 0
Const arabiccharset = 178
Const balticcharset = 186
Const chinesebig5 = 136
Const defaultcharset = 1
Const easteuropecharset = 238
Const easteurope = 238
Je suis parti du projet Enum Fonts trouvé là
http://allapi.mentalis.org/apilist/287C72333936CA5A15A4F5FAA476BD11.html
puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la polic=
e,
afficher son script.
FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)
(et ensuite les mêmes opérations pour s'arrêter au caractère nul)=
Pas de chance, comme résultat, j'ai ça :
Times New Roman : 0 (ansi)
Times New Roman CE : 2 (symbol)
Times New Roman CYR : 2 (symbol)
Times New Roman Greek : 1 (defaultcharacter)
Times New Roman TUR : 1 (defaultcharacter)
Times New Roman Baltic : 1 (defaultcharacter)
En résumé, aucun rapport avec la question.
Pour être bien sûr que nous parlons de la même chose : le nom de la=
police sans rien derrière, correspond au script d'Europe Occidentale.
Avec le suffixe CE, nous avons la même police dans le script d'Europe
Centrale. Avec le suffixe CYR, pour cyrillique, si je me rappelle bien
on s'adresse aux Russes (et on évite soigneusement de proposer ça par=
défaut, par exemple, en Tchéquie). Avec le suffixe TUR, il s'agit du =
script turc. Et Baltic vous devinez.
Je ne mets pas la main sur la sauvegarde de ce que j'ai fait il y a
quelques années, alors il faut que je le refasse. Apparemment, je ne li=
s
pas la valeur au bon endroit, quelqu'un pourrait-il me remettre dans le
droit chemin ?
Aussi bien, peut-être dois-je simplement conserver le suffixe derrièr=
e
le nom de la police ? J'ai bien l'impression que ça va être ça, mai=
s ce
que j'ai recueilli dans FontScript, alors, c'est quoi ?
Bon, ne vous fatiguez pas, ce sont justement mes bidouilles qui
n'étaient pas bien bordées.
J'ai perdu de vue que les membres de la structure LOGFONT ne sont pas
exactement du même type.
lfFaceName est un tableau de Bytes contenant une chaîne de caractères ,
raison pour laquelle il fallait le convertir ensuite par StrConv
lfCharSet, en revanche, est un Byte qui n'a pas à être converti en
chaîne de caractères.
Si je le lis directement en tant qu'entier, je reçois bien les valeurs
correspondant à mes constantes
Const ansi = 0
Const arabiccharset = 178
Const balticcharset = 186
Const chinesebig5 = 136
Const defaultcharset = 1
Const easteuropecharset = 238
Const easteurope = 238
Bon, désolé du dérangement ...
Gloops a écrit :
Tes constantes ne semblent pas complètes. Issues de WinGdi.h :
#define ANSI_CHARSET 0
#define DEFAULT_CHARSET 1
#define SYMBOL_CHARSET 2
#define SHIFTJIS_CHARSET 128
#define HANGEUL_CHARSET 129
#define HANGUL_CHARSET 129
#define GB2312_CHARSET 134
#define CHINESEBIG5_CHARSET 136
#define OEM_CHARSET 255
#if(WINVER >= 0x0400)
#define JOHAB_CHARSET 130
#define HEBREW_CHARSET 177
#define ARABIC_CHARSET 178
#define GREEK_CHARSET 161
#define TURKISH_CHARSET 162
#define VIETNAMESE_CHARSET 163
#define THAI_CHARSET 222
#define EASTEUROPE_CHARSET 238
#define RUSSIAN_CHARSET 204
Et pour les scripts lié aux fontes c'est plutôt du côté de l'api :
EnumFontFamiliesEx
qu'il faut se tourner, me semble t-il.
Un exemple ici :
disponible sur :
--
Cordialement,
Jacques.
Effectivement, je n'en ai mis qu'un petit échantillon pour situer de
quoi je parlais. Je n'avais d'ailleurs pas pensé à regarder dans
WinGdi.h, j'ai cherché quelques noms de constantes sur Internet et j'ai
eu une liste exploitable avec un des résultats.
Au fait, comme fichiers avec gdi dans le nom, j'ai GDI32.DLL, GDI.EXE,
quelques GdiPlus, et puis c'est tout (à part sur Internet bien entendu) .
Très intéressant, ça correspond bien à ce que je veux faire (à part
qu'après avoir affiché je ferai sélectionner une valeur).
Il y a peut-être une petite erreur dans la démonstration que j'ai vue ,
si on sélectionne le script par défaut on affiche toutes les valeurs,
mais c'est peut-être fait exprès.
Je ne me rappelais plus pourquoi je n'avais pas mis ça en Âœuvre sous
Access 95, c'est parce que AddressOf n'y est pas supporté.
Je soupçonne qu'avec Access 2003 ça devrait se passer mieux de ce cô té,
ça tombe bien parce que je crois qu'avec mon client actuel, installer u n
programme VB6 à côté, comme j'avais fait, ça représenterait du sport (si
ils ont des plantages ce n'est pas fait exprès).
En tout cas, cette fois, j'ai bien les billes voulues.
Merci pour cette mise au point.
Gloops a écrit :
WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seul.
A vrai dire, je n'ai pas regardé de près, mais cela semblait
correspondre à ta demande ...
AddressOf, me semble t-il est supporté sous Access 2003 (et même avant).
Par contre tu risques d'avoir des soucis (peut être pas insurmontables)
du côté de la propriété hDC, qui est nécessaire à certaines API's liées
aux fontes. Tu n'avais pas indiqué l'usage sous Access ...
A ma connaissance la propriété est hDC n'est pas disopnible par défault
dans les outils Office. :-(
--
Cordialement,
Jacques.
dans ce cas tout est normal :)
Effectivement
Avec la version 97, ce n'était en principe pas supporté, mais moyenna nt
un peu de gymnastique on finissait par s'en sortir.
Ah, ça laisse entendre qu'il risque d'y avoir du sport ?
Bon, on verra ça demain ...
Bon, finalement, pour le hDC sous Access, ça n'a guère été bien l ong.
=========== Début =========== ===
Declare Function GetDC Lib "user32" (ByVal hwnd As Long) As Long
Public Function DeviceContext(F As Form)
DeviceContext = GetDC(F.hwnd)
End Function
=========== Fin =========== ====
Ensuite, remplacer Form1.hDC par DeviceContext(Form1)
Par ailleurs, je remarque que le projet de vbAccelerator fonctionne à l a
maison, mais je travaille dans un environnement où installer un ocx
représenterait un marathon administratif, dont l'issue est d'ailleurs
incertaine, et qu'il faudrait multiplier par le nombre de postes. En
revanche, l'appel aux API ne pose pas de problème. ça tombe bien, j'a i
l'habitude de privilégier les appels aux API pour faciliter le
déploiement, moyennant quoi mon formulaire de sélection de script et de
police de caractères a été adapté en moins de deux heures.
J'ai dû avoir la berlu, j'aurais juré que j'avais vu "korean charset"
dans la liste. En fait à en croire quelques réponses trouvées dans
Google, il semble qu'en Corée on utilise plutôt Hangul.
Ah, je réalise à l'instant que j'ai déclaré ma fonction DeviceCon text
comme Variant par défaut plutôt que comme Long que retourne GetDC. Si
j'y pense j'y mettrai bon ordre.
Jacques pour ses précieux conseils.
Gloops a écrit :
Parfait :-)
S'il s'agit du contrôle ListView (associé à ListImage), tu peux le
remplacer par un ListBox ou un ComboBox, mais tu perdras l'image
associée à la fonte (TT : True Type, ou Fonte Imprimante). Une autre
option beaucoup plus lourde consiste à utiliser le contrôle ListView
présent dans ComCtl32.dll (qui fait partie d l'O.S.). L'ocx ne fait que
l'encapsuler :
Mais là, y'a du sport ;-)
Je ne le vois pas non plus dans Wingdi.h, par contre Hangeul ou Hangul
(129) semble bien correspondre à l'alphabet sino-coréen (mais je ne suis
pas familier avec)
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
Arial Unicode MS
Batang
@Arial Unicode MS
@Batang
Arial Unicode MS est liée à office me semble t-il (sauf pour XP) :
C'est vraiment de la fonte (en terme de poids) ;-) :
Arial Unicode MS : 22 Mo
Batang : 15 Mo
Les fontes débutants par le caractère @ apparaissent dans la liste du
programme VB, mais pas dans %windir%Fonts. J'en ignore la raison.
Vaudrai peut être mieux, les API's attende un Long, la conversion se
ferait elle ? à voir. En tout cas ce n'est pas une grosse modif :-)
--
Cordialement,
Jacques.
Merci Gloops :-)
--
Cordialement,
Jacques.
Effectivement, on dirait qu'il y a là de la matière intéressante, à
condition d'être prêt à passer plus de cinq minutes dessus.
Moi, pas encore trop non plus.
On va voir, si jamais une petite Coréenne me fait du gring ;)
Ah, ben là, je bosse pour un client qui commence à faire un gros
commerce avec la Corée, mais sur les postes normalisés de la boîte, il
n'y a pas encore de police de cette catégorie. ça va peut-être leur
faire un truc à ajouter.
Cela étant, à chacun son boulot, je leur développe une base, et ils se
débrouillent pour disposer des bonnes polices là où ils en ont beso in :)
De toute manière, installer les polices coréennes sur les postes en
France n'a de sens que si les Français sont en mesure de lire la langue
correspondante, et il ne semble pas que ce soit massivement le cas, les
échanges se font plutôt en Anglais.
J'ignore d'ailleurs si quelqu'un a une idée bien précise du protocole de
validation pour ce qui concerne le support des polices asiatiques. Je
soupçonne d'ailleurs qu'il serait de bon goût que j'avance des
propositions dans ce domaine. Si quelqu'un a une idée en la matière, ça
peut aider, même si j'ignore aujourd'hui ce qu'en fera le client.
ça y est, je viens de le faire, ça m'a évité de l'oublier. :)