Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic Sélection de police par scripts (sous VB6)

Sélection de police par scripts (sous VB6)

11 réponses
Avatar
Gloops
Bonjour tout le monde,

Je dois faire s=E9lectionner =E0 mon utilisateur une police de caract=E8r=
es=20
parmi celles disponibles dans le script de son pays.

Aussi, j'ai charg=E9 les constantes correspondantes :
Const ansi =3D 0
Const arabiccharset =3D 178
Const balticcharset =3D 186
Const chinesebig5 =3D 136
Const defaultcharset =3D 1
Const easteuropecharset =3D 238
Const easteurope =3D 238

Je suis parti du projet Enum Fonts trouv=E9 l=E0
http://allapi.mentalis.org/apilist/287C72333936CA5A15A4F5FAA476BD11.html

puis j'ai un peu bidouill=E9 l=E0-dedans pour, en plus du nom de la polic=
e,=20
afficher son script.

FontName =3D StrConv(LF.lfFaceName, vbUnicode)
FontScript =3D StrConv(LF.lfCharSet, vbUnicode)

(et ensuite les m=EAmes op=E9rations pour s'arr=EAter au caract=E8re nul)=


Pas de chance, comme r=E9sultat, j'ai =E7a :

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=E9sum=E9, aucun rapport avec la question.

Pour =EAtre bien s=FBr que nous parlons de la m=EAme chose : le nom de la=
=20
police sans rien derri=E8re, correspond au script d'Europe Occidentale.=20
Avec le suffixe CE, nous avons la m=EAme police dans le script d'Europe=20
Centrale. Avec le suffixe CYR, pour cyrillique, si je me rappelle bien=20
on s'adresse aux Russes (et on =E9vite soigneusement de proposer =E7a par=
=20
d=E9faut, par exemple, en Tch=E9quie). 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=20
quelques ann=E9es, alors il faut que je le refasse. Apparemment, je ne li=
s=20
pas la valeur au bon endroit, quelqu'un pourrait-il me remettre dans le=20
droit chemin ?

Aussi bien, peut-=EAtre dois-je simplement conserver le suffixe derri=E8r=
e=20
le nom de la police ? J'ai bien l'impression que =E7a va =EAtre =E7a, mai=
s ce=20
que j'ai recueilli dans FontScript, alors, c'est quoi ?
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Gloops
Gloops a écrit, le 10/11/2007 19:18 :
puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la pol ice,
afficher son script.



Bon, ne vous fatiguez pas, ce sont justement mes bidouilles qui
n'étaient pas bien bordées.


FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)



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 ...
Avatar
Jacques93
Bonjour Gloops,
Gloops a écrit :
Bonjour tout le monde,

Je dois faire sélectionner à mon utilisateur une police de caractères
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 police,
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 lis
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ère
le nom de la police ? J'ai bien l'impression que ça va être ça, mais ce
que j'ai recueilli dans FontScript, alors, c'est quoi ?



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 :

<http://www.vbaccelerator.com/codelib/enum/enumfont.zip>

disponible sur :

<http://www.vbaccelerator.com/codelib/enum/enum.htm>

--
Cordialement,

Jacques.
Avatar
Gloops
Jacques93 a écrit, le 10/11/2007 20:37 :
Tes constantes ne semblent pas complètes. Issues de WinGdi.h :



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) .


Et pour les scripts lié aux fontes c'est plutôt du côté de l'ap i :

EnumFontFamiliesEx

qu'il faut se tourner, me semble t-il.

Un exemple ici :

<http://www.vbaccelerator.com/codelib/enum/enumfont.zip>



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.


disponible sur :

<http://www.vbaccelerator.com/codelib/enum/enum.htm>




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.
Avatar
Jacques93
Bonjour Gloops,
Gloops a écrit :
Jacques93 a écrit, le 10/11/2007 20:37 :
Tes constantes ne semblent pas complètes. Issues de WinGdi.h :



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).



WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seul.


<http://www.vbaccelerator.com/codelib/enum/enumfont.zip>



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.



A vrai dire, je n'ai pas regardé de près, mais cela semblait
correspondre à ta demande ...


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 un
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.




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.
Avatar
Gloops
Jacques93 a écrit, le 10/11/2007 23:04 :
WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seu l.



dans ce cas tout est normal :)

A vrai dire, je n'ai pas regardé de près, mais cela semblait
correspondre à ta demande ...



Effectivement

AddressOf, me semble t-il est supporté sous Access 2003 (et même av ant).
Par contre tu risques d'avoir des soucis (peut être pas insurmontable s)
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 ...



Avec la version 97, ce n'était en principe pas supporté, mais moyenna nt
un peu de gymnastique on finissait par s'en sortir.



A ma connaissance la propriété est hDC n'est pas disopnible par dé fault
dans les outils Office. :-(




Ah, ça laisse entendre qu'il risque d'y avoir du sport ?
Bon, on verra ça demain ...
Avatar
Gloops
Bonsoir,

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.
Avatar
Gloops
Une conclusion s'impose qu'il ne faudrait pas avoir oubliée : merci à
Jacques pour ses précieux conseils.
Avatar
Jacques93
Bonjour Gloops,
Gloops a écrit :
Bonsoir,

Bon, finalement, pour le hDC sous Access, ça n'a guère été bien long.

=========== 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)



Parfait :-)

Par ailleurs, je remarque que le projet de vbAccelerator fonctionne à la
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'ai
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.




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 :

<http://btmtz.mvps.org/listview/>

Mais là, y'a du sport ;-)


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.



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) :

<http://office.microsoft.com/fr-fr/help/HP052558401036.aspx?pid=CL100605171036>

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.

Ah, je réalise à l'instant que j'ai déclaré ma fonction DeviceContext
comme Variant par défaut plutôt que comme Long que retourne GetDC. Si
j'y pense j'y mettrai bon ordre.



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.
Avatar
Jacques93
Gloops a écrit :
Une conclusion s'impose qu'il ne faudrait pas avoir oubliée : merci à
Jacques pour ses précieux conseils.



Merci Gloops :-)

--
Cordialement,

Jacques.
Avatar
Gloops
Jacques93 a écrit, le 12/11/2007 18:56 :
[pb intégration ocx]



S'il s'agit du contrôle ListView (associé à ListImage), tu peux l e
remplacer par un ListBox ou un ComboBox, mais tu perdras l'image
associée à la fonte (TT : True Type, ou Fonte Imprimante). Une autr e
option beaucoup plus lourde consiste à utiliser le contrôle ListVie w
présent dans ComCtl32.dll (qui fait partie d l'O.S.). L'ocx ne fait q ue
l'encapsuler :

<http://btmtz.mvps.org/listview/>

Mais là, y'a du sport ;-)



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.




J'ai dû avoir la berlu, j'aurais juré que j'avais vu "korean chars et"
dans la liste. En fait à en croire quelques réponses trouvées da ns
Google, il semble qu'en Corée on utilise plutôt Hangul.



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)



Moi, pas encore trop non plus.
On va voir, si jamais une petite Coréenne me fait du gring ;)


Je peux juste te dire que chez moi, il y a 4 fontes Hangul :



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.

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 :-)




ça y est, je viens de le faire, ça m'a évité de l'oublier. :)
1 2