(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 ?
(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 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 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 :
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 :
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.
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 :
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.
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 :
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.
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.
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.
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.
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. :-(
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.
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.
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 ...
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 ...
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 ...
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.
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.
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.
Gloops
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.
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) :
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.
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) :
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 :-)
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) :
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.
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.
Gloops a écrit :
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.
Merci Gloops :-)
-- Cordialement,
Jacques.
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. :)
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. :)
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. :)