Coloration syntaxique dans l'Editeur

La coloration syntaxique s'applique pour les mots-clé trouvés à l'intérieur des REM, ce que je trouve un peu gênant.

Remarque: elle ne s'applique pas pour les mots-clé suivants (liste non exhaustive):
RIGHT$, LEFT$, MID$, CHR$, STR$, STRING$, LTRIM$, RTRIM$, TRIM$, LEN, VAL, FILE_EOF(), FILE_NAME$

Eh oui, tous les mots-clés qui étaient suivis d'une parenthèse ouvrante n'étaient pas colorés.

Ce bug est corrigé dans la version disponible au téléchargement.

Quant aux mots-clés qui sont dans une ligne REM et qui sont colorés, la correction n'est pas si évidente à faire. Elle attendra quelques jours car je vais prendre un peu de vacances.

C'était juste une remarque, et ça peut attendre !

En tout cas; BONNES VACANCES !, bien méritées.

---------------------------------------------------------------------------------
Pour la rentrée:
Suggestions d'amélioration de l'Editeur:
- Demander confirmation pour quitter s'il y a eu modifications du source non enregistrées (surprise désagréable, si on clique par erreur sur quitter).
La fonction de réécriture du source (icône disquette) devrait réécrire d'office dans le source d'origine s'il a déjà un nom. Par exemple j'ouvre Toto.bas, je fais des modifs, je clique sur la disquette, il devrait me réécrire en Toto.bas sans rien demander. Et peut-être demander seulement si on utilise le "Sauvegarder" du menu à défaut d'une option "Sauvegarder sous..."
- Plus difficile: une fonction de recherche (et remplacement ?) de séquence...

Une remarque concernant les chaînes de caractères:
Il est interdit de comparer deux chaînes: par exemple IF a$ > b$.
Je sais, ce n'est pas très orthodoxe, mais c'est bien pratique parfois pour trier, ou par exemple pour comparer deux dates de la forme AAAAMMJJ.
Et c'était permis en QBasic (et c'est permis en RapidQ), d'où mes mauvaises habitudes.

Encore une remarque: Fonction VAL(string$)
La fonction part en erreur si la chaîne contient des espaces, ce qui arrive si la chaîne numérique contient des séparateurs de milliers comme c'est fréquent. Il faut au préalable passer dans un sous-programme qui supprime les espaces.
Par exemple VAL("2 304.46") part en erreur, alors que d'autres Basics (QBasic et RapidQ) donnent la valeur correcte 2304.46.
En fait il y a erreur dès que la chaîne contient autre chose qu'un chiffre ou un point. VAL("31a2") donne une erreur, alors que QBasic et RapidQ donnent la valeur 31 (arrêt au 1er caractère non chiffre ou point ou espace).

PS J'édite au fur et à mesure pour ne pas multiplier les sujets, peut-être à tort ?

Citation :

Suggestions d'amélioration de l'Editeur:
- Demander confirmation pour quitter s'il y a eu modifications du source non enregistrées (surprise désagréable, si on clique par erreur sur quitter).
La fonction de réécriture du source (icône disquette) devrait réécrire d'office dans le source d'origine s'il a déjà un nom. Par exemple j'ouvre Toto.bas, je fais des modifs, je clique sur la disquette, il devrait me réécrire en Toto.bas sans rien demander. Et peut-être demander seulement si on utilise le "Sauvegarder" du menu à défaut d'une option "Sauvegarder sous..."
- Plus difficile: une fonction de recherche (et remplacement ?) de séquence...

Une remarque concernant les chaînes de caractères:
Il est interdit de comparer deux chaînes: par exemple IF a$ > b$.
Je sais, ce n'est pas très orthodoxe, mais c'est bien pratique parfois pour trier, ou par exemple pour comparer deux dates de la forme AAAAMMJJ.
Et c'était permis en QBasic (et c'est permis en RapidQ), d'où mes mauvaises habitudes.

Encore une remarque: Fonction VAL(string$)
La fonction part en erreur si la chaîne contient des espaces, ce qui arrive si la chaîne numérique contient des séparateurs de milliers comme c'est fréquent. Il faut au préalable passer dans un sous-programme qui supprime les espaces.
Par exemple VAL("2 304.46") part en erreur, alors que d'autres Basics (QBasic et RapidQ) donnent la valeur correcte 2304.46.
En fait il y a erreur dès que la chaîne contient autre chose qu'un chiffre ou un point. VAL("31a2") donne une erreur, alors que QBasic et RapidQ donnent la valeur 31 (arrêt au 1er caractère non chiffre ou point ou espace).

C'est tout plein de bonnes idées tout ça!

Je vais en tenir compte pour les prochaines versions. Mon désir secret (mais qui ne l'est plus maintenant que je le révèle), c'est que PANORAMIC devienne au moins l'équivalent de RapidQ, qui était un bon logiciel, que j'ai beaucoup utilisé, mais qui malheureusement, n'est plus du tout maintenu.

Citation :

J'édite au fur et à mesure pour ne pas multiplier les sujets

Tu peux multiplier les sujets, je tiendrai compte de tous. Je prends en compte toutes les remarques et suggestions, mais il faut du temps pour qu'elles deviennent réalité...

Merci pour ta réponse.
C'est vrai que RapidQ est très puissant et bien documenté, mais il n'évolue plus. Pour moi je préfère maintenant Panoramic, plus simple à manipuler et... très dynamique !