Merci pour ce retour d'information.El Papounet a écrit :J'ai réussi à faire fonctionner ton code en modifiant quelque peu les chemins d'accès du compilateur et du source généré.
Est-ce que tu peux poster le code corrigé ? (dans le sujet "e-cqcm")
Les choix des chemins ont été faits pour éviter de retrouver son source circuler hors contrôle sur Internet. Et pour apporter le moins possible de confusion en se demandant qu'est-ce que ferait ce fichier à tel ou tel endroit.
Aussi je me mets à ta place pour comprendre l'expression << c'est se compliquer l'existence >>. Très vite, je dirai que oui hélas : je découvre un code source qui n'est pas de moi. Le but vanté : se simplifier la vie. Double pavasse qui ne fonctionne pas... Obligé d'aller déboguer je ne sais quel slash de courtoisie au milieu d'un tas d'instructions compliquées sensées se simplifier la vie...
C'est effectivement très contradictoire !
Mais c'est pour bien avoir devant les yeux la totalité du fonctionnement du système depuis le code source jusqu'à son exécution. C'est le décor et les coulisses à la fois. Il n'y a pas de plaisir à faire fonctionner ce système, comme un jeu, ou un logiciel rentable.
Là je montre un décor, ses coulisses et j'explique comment ériger une part de ces coulisses. Je n'explique pas assez pourquoi cette méthode de montage est enrichissante pour celui qui la comprend. Je n'explique pas non plus cette procédure qui, parmi les autres vient convertir et enlever les accents. Bref, faire finalement le principal du travail de pré-processing.
Mais je n'ai pas mis d'instruction de suppression du fichier TRANSIT.PB. Ce fichier temporaire normalisé pour être compilé, et systématiquement écrasé par la compilation suivante.
Un système "propre" et net, supprime ses fichiers temporaires. Là non, c'est vraiment pour pouvoir vérifier et étudier, par la pratique, comment ça procède.
Mais ce procédé que je n'ai pas expliqué est un exemple de procédé. Celui-là, par exemple, discrimine les programmeurs selon leur langue natale. Les langues cyrilliques et hébraïques sont réduites, tandis que les langues asiatiques sont largement gagnantes. Et la langues françaises est entre les deux, puisque ses accents restent une exception. Cette discrimination est dûe à la limitation du nombre de caractères.
Il est très loin d'être parfait ce procédé. Je pourrai faire un procédé parfait, mais là, les coulisses seraient imbuvables pour celui qui découvre.
Pour conclure, je ne serai pas raisonnable de m'écrier que << Si, si : ça simplifie l'existence, quand on veut rassembler une équipe internationale, il y a une barrière qui est pulvérisée. Ça se voit même à l'IRM ! >>. Non...
Donc, tu as raison, en l'état, ça complique l'existence ! Mais ça t'indique que la gestion de chaîne est infinie à côté des macros, tandis que les macros ont un plafond extrêmement limité de fonctionnement. Traduction : il vaut mieux mettre "print" entre guillemets et gérer des Ucase(), des Lcase(), des StringField(), des Mid(), etc... que de mettre "print" entre les balises d'une macro. On ne peut même pas remplacer un accent avec une macro... Et quand bien même de la sueur coulerait pour y parvenir lors d'une mise à jour du compilateur, il resterait encore une infinité de mécaniques impossibles avec les macros, puisque leur but est de remplacer en un seul balayage de code source telles expressions limitées à l'ASCII 7 bits par telles expressions.
La subtilité c'est que c'est un mode d'emploi, pas un projet, un projet où je ferai dépendre des intéressés de mes volontés de le faire évoluer ou non.