verdy_p
Messages postés202Date d'inscriptionvendredi 27 janvier 2006StatutMembreDernière intervention29 janvier 2019 13 oct. 2008 à 05:29
Pour les encodages, arrêtez de parler de codage "ANSI" (ni même "OEM") c'est tout sauf portable. Parlez de pages de codes (car ça change d'une machine à l'autre en fonction de l'installation de Windows ou de l'environnement de l'utilisateur). ANSI et OEM font partie de ce qu'on appelle les paramètres de locale.
Si vous voulez réellement supporter tous les utilisateurs de Windows (ou DOS) et permettre les conversions, allez dnoc chercher les tables de transcodage sur le site Unicode: Pour les codages Windows il faut déjà une douzaine de pages de code, il en faut encore plus pour les pages de code OEM (auxquelles il faut ajouter des pages de code non créées par IBM mais par des organismes nationaux de normalisation, comme les codes KOI-8R (Russie) et KOI8-U (Ukraine), VISCII (Vietnam), ISCII (une douzaine de codes pour les écritures indiennes), TIS-620 (et plusieurs autres variantes utilisées en Thailande, dont une seule corerspond à la page de code Windows pour le Thai), les pages de code grecques, arabes, hébreues, ArmSCII (écriture arménienne), GSTD (écriture géorgienne), sans compter les variantes de pages de code multioctets japonaises, chinoises, et coréennes... A cela il faudrait ajouter les jeux de caractère HP (comme Roman8 et d'autres), IBM (EBCDIC avec ses variantes), Apple (Mac).
Pour supporter le tout, il vaut mieux que l'éditeur en interne utilise exclusivement Unicode (UTF-16 ou UTF-32) et supporte en plus plusieurs encodages Unicode en entrée-sortie de/vers les fichiers édités (UTF-8, UTF-16, UTF-32, ou l'un des codages compressés décrits dans la norme, avec en plus les variantes little-endian et big-endian pour UTF-16 et UTF-32, et l'utilisation ou non des BOM en tête)
Windows supporte une API pour ces conversions (cela nécessite de connaitre les numéros de pages de code assignées à chacun de ces codages, et l'installation préalable sur le système du support de ces pages de code (dans les paramètres régionaux du panneau de configuration de l'administrateur)
Sinon il faudra inclure les tables de transcodage dans le programme (on peut utiliser des librairies toutes faites comme GNU iconv ou ICU. On trouve une liste à peu près complète de ces librairies ici:
http://www.unicode.org/resources/libraries.html
Il y manque encore KOI8-U pour les Ukrainiens et les Bulgaresn, mais les quelques différences avec KOI-8R sont documentées par exemple sur Wikipédia:
http://fr.wikipedia.org/wiki/KOI8-U
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 12 oct. 2008 à 17:58
Je pense qu'il y a un problème au niveau des menus : les images sont trop petites et n'apparaissent pas en entier.
Par ailleurs, les menus du style "co&Pier" ne donnent pas un très bon résultat (pourquoi mettre une majuscule au P?).
Pour ce qui est du code, tu ne devrais pas mettre la définition de tes fonctions directement dans les headers. Sauf cas particulier, il faut uniquement mettre les prototypes dans le .h et mettre le code dans des .cpp.
Pareil pour les variables, ne par les définir dans un .h (sinon tu aura des problèmes sur plusieurs fichiers doivent insérer le même header).
Ta boite de dialogue "Syntaxe" est bien trop grande, elle ne tient dans sur l'écran en 1280*800 qui est une résolution assez courante.
Plus généralement, on utilise généralement la police Tahoma pour les boites de dialogue (en ajoutant FONT 8,"MS Shell Dlg",400,0,1 dans le script). Ca prend déja moins de place.
Quelques détails:
Je trouve que la mise en forme du code le rend difficile à lire (indentation un peu spéciale a mon avis).
if ( strlen(lpszArgument)>0 ) : pour savoir si une chaine est vide en C, tu as beaucoup plus rapide comme méthode (en temps d'exécution) : if(*lpszArgument). Car strlen est d'autant plus long à s'exécuter que la chaine est longue.
Voila c'est tout, j'ai pas trop le temps de regarder le code en détail
uaip
Messages postés1466Date d'inscriptionmardi 20 février 2007StatutMembreDernière intervention 7 février 2011 12 oct. 2008 à 14:57
Ah oui bon ben, j'avais fait la connerie d'ouvrir l'exe sans dézipper ^^.
En effet c'est pas mal niveau 'rendu graphique' (les icones dans les menus, le changement de langue, la présentation du document, etc).
Par contre, je n'ai pas réussi à colorer le texte.
Donc oui, mise à part les DialogBoxes un peu disproportionnées à mon gout, c'est vraiment pas mal.
uaip
Messages postés1466Date d'inscriptionmardi 20 février 2007StatutMembreDernière intervention 7 février 2011 12 oct. 2008 à 14:48
Concernant l'aide de Scintilla, j'ai eu également beaucoup de mal à comprendre (et encore maintenant) mais en regardant leurs démos, etc, j'ai réussi à comprendre un peu le fonctionnement des lexers, folding, margins, etc.
Pour ce qui est du tuto... pourquoi pas en effet ^^ mais pour le moment j'ai pas mal de boulot (et oui, l'école...) puis je ne suis pas très doué pour expliquer ce genre de choses. M'enfin, pourquoi ne pas essayer, en effet.
Je re-teste ton appli et j'approfondis mes remarques (sur le fait que ça plante).
cs_bultez
Messages postés13615Date d'inscriptionjeudi 13 février 2003StatutMembreDernière intervention15 octobre 201330 12 oct. 2008 à 14:43
@brunews : faut bien continuer à apprendre
j'ai rectifié ce que tu signale, mais
j' attend un peu plus de ta part ! ;o)
@fabricelepro : t'as raison, c'est à ajouter.
@petifa : >>plus "standardisé".
certes... mais ça me conviendrait beaucoup moins
>>le rendu est assez sympathique.
merci à toi.
@uaip >>Pour ma part, ça plante...
ah bon ? mais sans plus d' infos... je ne peux rien expliquer !
déjà qu'avec plus de données, j'aurais du mal !
>>J'ai enfin compris (après de nombreux essais foireux)
t'as raison... et je foire toujours !
c'est pas si simple... et la doc dans un
patois auquel je ne comprend que peu de choses !
dieu me tripote : qu'attends-tu donc pour nous faire un
ch'tiot "tuto" ? dans la langue de Vian ou de Prévert ?
je peine encore sur de nombreuses choses !
ça me permettrait d'avancer, de suivre, voire de maîtriser ( ? )
>>fenêtres d'options immenses, editbox disproportionnées,
pas pu mieux faire [ pour l'instant (?) ] ;o)
merci à tous.
uaip
Messages postés1466Date d'inscriptionmardi 20 février 2007StatutMembreDernière intervention 7 février 2011 12 oct. 2008 à 02:31
Pour ma part, ça plante dès que j'ouvre un nouveau document...
C'est bien dommage étant donné que je prends beaucoup de plaisir à programmer en utilisant Scintilla.
Si tu tiens à auto-indenter, ou numéroter les lignes, je peux t'aider. J'ai enfin compris (après de nombreux essais foireux) comment fonctionnait cette jolie dll. Il y a aussi le folding qui peut être intéressant. Des exemples sont sur le site de Scintilla.
Je regarderai, quand j'en aurais le temps, comment tu as géré les lexers.
(et c'est vrai que l'effet graphique de ton appli n'est pas très réussie... fenêtres d'options immenses, editbox disproportionnées, etc)
Bonne continuation tout de même.
cs_petifa
Messages postés215Date d'inscriptiondimanche 20 février 2005StatutMembreDernière intervention10 mars 2014 11 oct. 2008 à 21:57
le menu pourrait être un peu mieux organiser aussi, ca serait plus facile a l'utilisation et aussi plus "standardisé".
pas eu le temps de checker tout le code mais le rendu est assez sympathique.
fabricelepro
Messages postés21Date d'inscriptionvendredi 7 décembre 2012StatutMembreDernière intervention 3 janvier 2009 11 oct. 2008 à 21:29
Salut
je pense bien que tu pourrais mettre une partie pour l'impression
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 11 oct. 2008 à 19:10
Ben te voila sur cppfrance...
OPENFILENAME ofn;
la structure est sur la pile, un simple: sub esp, sizeof(OPENFILENAME)
Il n'y a donc aucune alloc de mélmoire,
donc nenni: delete[] &ofn;
13 oct. 2008 à 05:29
Si vous voulez réellement supporter tous les utilisateurs de Windows (ou DOS) et permettre les conversions, allez dnoc chercher les tables de transcodage sur le site Unicode: Pour les codages Windows il faut déjà une douzaine de pages de code, il en faut encore plus pour les pages de code OEM (auxquelles il faut ajouter des pages de code non créées par IBM mais par des organismes nationaux de normalisation, comme les codes KOI-8R (Russie) et KOI8-U (Ukraine), VISCII (Vietnam), ISCII (une douzaine de codes pour les écritures indiennes), TIS-620 (et plusieurs autres variantes utilisées en Thailande, dont une seule corerspond à la page de code Windows pour le Thai), les pages de code grecques, arabes, hébreues, ArmSCII (écriture arménienne), GSTD (écriture géorgienne), sans compter les variantes de pages de code multioctets japonaises, chinoises, et coréennes... A cela il faudrait ajouter les jeux de caractère HP (comme Roman8 et d'autres), IBM (EBCDIC avec ses variantes), Apple (Mac).
Pour supporter le tout, il vaut mieux que l'éditeur en interne utilise exclusivement Unicode (UTF-16 ou UTF-32) et supporte en plus plusieurs encodages Unicode en entrée-sortie de/vers les fichiers édités (UTF-8, UTF-16, UTF-32, ou l'un des codages compressés décrits dans la norme, avec en plus les variantes little-endian et big-endian pour UTF-16 et UTF-32, et l'utilisation ou non des BOM en tête)
Windows supporte une API pour ces conversions (cela nécessite de connaitre les numéros de pages de code assignées à chacun de ces codages, et l'installation préalable sur le système du support de ces pages de code (dans les paramètres régionaux du panneau de configuration de l'administrateur)
Sinon il faudra inclure les tables de transcodage dans le programme (on peut utiliser des librairies toutes faites comme GNU iconv ou ICU. On trouve une liste à peu près complète de ces librairies ici:
http://www.unicode.org/resources/libraries.html
Sur le site Unicode les tables de transcodage de base (une partie seulement) sont en téléchargement libre ici:
http://www.unicode.org/Public/MAPPINGS/
Il y manque encore KOI8-U pour les Ukrainiens et les Bulgaresn, mais les quelques différences avec KOI-8R sont documentées par exemple sur Wikipédia:
http://fr.wikipedia.org/wiki/KOI8-U
12 oct. 2008 à 17:58
Par ailleurs, les menus du style "co&Pier" ne donnent pas un très bon résultat (pourquoi mettre une majuscule au P?).
Pour ce qui est du code, tu ne devrais pas mettre la définition de tes fonctions directement dans les headers. Sauf cas particulier, il faut uniquement mettre les prototypes dans le .h et mettre le code dans des .cpp.
Pareil pour les variables, ne par les définir dans un .h (sinon tu aura des problèmes sur plusieurs fichiers doivent insérer le même header).
Ta boite de dialogue "Syntaxe" est bien trop grande, elle ne tient dans sur l'écran en 1280*800 qui est une résolution assez courante.
Plus généralement, on utilise généralement la police Tahoma pour les boites de dialogue (en ajoutant FONT 8,"MS Shell Dlg",400,0,1 dans le script). Ca prend déja moins de place.
Quelques détails:
Je trouve que la mise en forme du code le rend difficile à lire (indentation un peu spéciale a mon avis).
if ( strlen(lpszArgument)>0 ) : pour savoir si une chaine est vide en C, tu as beaucoup plus rapide comme méthode (en temps d'exécution) : if(*lpszArgument). Car strlen est d'autant plus long à s'exécuter que la chaine est longue.
Voila c'est tout, j'ai pas trop le temps de regarder le code en détail
12 oct. 2008 à 14:57
En effet c'est pas mal niveau 'rendu graphique' (les icones dans les menus, le changement de langue, la présentation du document, etc).
Par contre, je n'ai pas réussi à colorer le texte.
Donc oui, mise à part les DialogBoxes un peu disproportionnées à mon gout, c'est vraiment pas mal.
12 oct. 2008 à 14:48
Pour ce qui est du tuto... pourquoi pas en effet ^^ mais pour le moment j'ai pas mal de boulot (et oui, l'école...) puis je ne suis pas très doué pour expliquer ce genre de choses. M'enfin, pourquoi ne pas essayer, en effet.
Je re-teste ton appli et j'approfondis mes remarques (sur le fait que ça plante).
12 oct. 2008 à 14:43
j'ai rectifié ce que tu signale, mais
j' attend un peu plus de ta part ! ;o)
@fabricelepro : t'as raison, c'est à ajouter.
@petifa : >>plus "standardisé".
certes... mais ça me conviendrait beaucoup moins
>>le rendu est assez sympathique.
merci à toi.
@uaip >>Pour ma part, ça plante...
ah bon ? mais sans plus d' infos... je ne peux rien expliquer !
déjà qu'avec plus de données, j'aurais du mal !
>>J'ai enfin compris (après de nombreux essais foireux)
t'as raison... et je foire toujours !
c'est pas si simple... et la doc dans un
patois auquel je ne comprend que peu de choses !
dieu me tripote : qu'attends-tu donc pour nous faire un
ch'tiot "tuto" ? dans la langue de Vian ou de Prévert ?
je peine encore sur de nombreuses choses !
ça me permettrait d'avancer, de suivre, voire de maîtriser ( ? )
>>fenêtres d'options immenses, editbox disproportionnées,
pas pu mieux faire [ pour l'instant (?) ] ;o)
merci à tous.
12 oct. 2008 à 02:31
C'est bien dommage étant donné que je prends beaucoup de plaisir à programmer en utilisant Scintilla.
Si tu tiens à auto-indenter, ou numéroter les lignes, je peux t'aider. J'ai enfin compris (après de nombreux essais foireux) comment fonctionnait cette jolie dll. Il y a aussi le folding qui peut être intéressant. Des exemples sont sur le site de Scintilla.
Je regarderai, quand j'en aurais le temps, comment tu as géré les lexers.
(et c'est vrai que l'effet graphique de ton appli n'est pas très réussie... fenêtres d'options immenses, editbox disproportionnées, etc)
Bonne continuation tout de même.
11 oct. 2008 à 21:57
pas eu le temps de checker tout le code mais le rendu est assez sympathique.
11 oct. 2008 à 21:29
je pense bien que tu pourrais mettre une partie pour l'impression
11 oct. 2008 à 19:10
OPENFILENAME ofn;
la structure est sur la pile, un simple: sub esp, sizeof(OPENFILENAME)
Il n'y a donc aucune alloc de mélmoire,
donc nenni: delete[] &ofn;
Pas le temps de voir le reste.