puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la pol ice,
afficher son script.
FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)
puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la pol ice,
afficher son script.
FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)
puis j'ai un peu bidouillé là-dedans pour, en plus du nom de la pol ice,
afficher son script.
FontName = StrConv(LF.lfFaceName, vbUnicode)
FontScript = StrConv(LF.lfCharSet, vbUnicode)
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 ?
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 ?
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 :
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>
disponible sur :
<http://www.vbaccelerator.com/codelib/enum/enum.htm>
Tes constantes ne semblent pas complètes. Issues de WinGdi.h :
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>
disponible sur :
<http://www.vbaccelerator.com/codelib/enum/enum.htm>
Tes constantes ne semblent pas complètes. Issues de WinGdi.h :
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>
disponible sur :
<http://www.vbaccelerator.com/codelib/enum/enum.htm>
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).
<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.
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.
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).
<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.
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.
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).
<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.
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.
WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seu l.
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 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 ...
A ma connaissance la propriété est hDC n'est pas disopnible par dé fault
dans les outils Office. :-(
WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seu l.
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 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 ...
A ma connaissance la propriété est hDC n'est pas disopnible par dé fault
dans les outils Office. :-(
WinGdi.h est livré avec Visual Studio et/ou Visual C, pas avec VB seu l.
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 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 ...
A ma connaissance la propriété est hDC n'est pas disopnible par dé fault
dans les outils Office. :-(
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)
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.
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 DeviceContext
comme Variant par défaut plutôt que comme Long que retourne GetDC. Si
j'y pense j'y mettrai bon ordre.
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)
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.
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 DeviceContext
comme Variant par défaut plutôt que comme Long que retourne GetDC. Si
j'y pense j'y mettrai bon ordre.
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)
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.
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 DeviceContext
comme Variant par défaut plutôt que comme Long que retourne GetDC. Si
j'y pense j'y mettrai bon ordre.
Une conclusion s'impose qu'il ne faudrait pas avoir oubliée : merci à
Jacques pour ses précieux conseils.
Une conclusion s'impose qu'il ne faudrait pas avoir oubliée : merci à
Jacques pour ses précieux conseils.
Une conclusion s'impose qu'il ne faudrait pas avoir oubliée : merci à
Jacques pour ses précieux conseils.
[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 ;-)
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)
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
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 :-)
[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 ;-)
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)
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
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 :-)
[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 ;-)
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)
Je peux juste te dire que chez moi, il y a 4 fontes Hangul :
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 :-)