BULLET MINI EDITEUR DE TEXTES MULTI-DOCUMENTS, COLORATION SYNTAXIQUE MULTI-LANGA
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
11 oct. 2008 à 19:10
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 13 oct. 2008 à 05:29
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 13 oct. 2008 à 05:29
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/48171-bullet-mini-editeur-de-textes-multi-documents-coloration-syntaxique-multi-langages
https://codes-sources.commentcamarche.net/source/48171-bullet-mini-editeur-de-textes-multi-documents-coloration-syntaxique-multi-langages
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.