Suggestions d'améliorations diverses

Un résumé des questions que j'ai soulevées sur le forum langue anglaise:
- Utilisation de l'IDE: conservation de l'option langue choisie pour les sessions ultérieures.
- EXECUTE: possibilité de passer des paramètres au programme externe appelé. FAIT
-FICHIERS: possibilité de Lire/Ecrire n octets à partir d'une position quelconque dans le fichier (implicitement le pointeur courant).
- PRINT: possibilité d'écrire à un emplacement donné x,y de l'objet (Locate). FAIT
Possibilité d'écrire sur imprimante (avec police/taille ?)

- Est-il possible de reprendre le déroulement de l'application après une commande STOP (pour débogage, comme on fait en Basic avec F5) ?

- La limitation du nombre de variables déclarées à 14 devient gênante dès que le programme s'allonge un peu (enfin, pour moi qui viens directement du Basic). Et on ne peut pas supprimer une variable devenue inutile pour en définir une autre avec la place gagnée.

- De même la limitation de la taille des tableaux risque d'être rédhibitoire (toujours en ce qui me concerne)

REMARQUE: si je lance dans l'Editor le programme FONTS.bas donné en exemple dans la section 'Exemples', je récupère l'erreur "Too Many Labels Line:3" (je compte 13 labels) ?????

Je viens de mettre sur le site une version de PANORAMIC_IDE et de PANORAMIC_EDITOR qui permettent d'appeler un programme externe en lui passant des paramètres.
La commande est EXECUTE, dont la syntaxe a été modifiée:
EXECUTE "PRG.EXE" pour lancer PRG.EXE sans paramètre,
EXECUTE "PRG.EXE 20" pour lancer PRG.EXE en lui passant 20 en paramètre,
EXECUTE "PRG.EXE 20 5" pour lancer PRG.EXE en lui passant 20 et 5 en paramètres, etc.

Les autres demandes sont à l'étude:
- mémoriser la langue de travail plutôt que d'avoir à la choisir à chaque fois,
- lecture/écriture de n octets dans un fichier à partir d'une position donnée,
- impression sur un objet à un endroit déterminé en X et Y,
- impression sur imprimante,
- choix d'une imprimante.

La commande EXECUTE d'un programme avec ses paramètres fonctionne très bien, merci.

Quelques remarques supplémentaires (NB: je viens directement du QBasic et j'essaie de retrouver mes repères, aussi ne m'en veuillez pas si certaines remarques sont inappropriées).

- Si j'écris

Code:

  ... 
  GOTO Etiq
  .....
  .....
  Etiq:

je tombe en erreur: Not A Legal Label Line 8 (ligne de l'étiquette) ?
Pardon, j'ai trouvé: il faut définir préalablement l'étiquette avec LABEL

- Graphismes 2D
Les figures fermées (2D_RECTANGLE, 2D_CIRCLE) sont implicitement remplies de la couleur de fond de l'objet, ce qui efface les tracés qui sont au-dessous de ces figures. Y a-t-il moyen d'avoir une couleur de remplissage 'transparente' ?

- Fichiers
les propositions plus haut concernant l'accès aux fichiers au niveau de l'octet supposent sans doute également l'usage de fonctions équivalentes à EOF (test de fin de fichier) et à SEEK (lecture ou fixation du pointeur dans le fichier).

- Boucles
Y a-t-il une fonction de sortie prématurée sous condition de boucle ou de SUB : par exemple EXIT FOR, ou EXIT SUB ? je n'en ai pas trouvé dans la liste des mots-clés.

Les figures 2D_CIRCLE et 2D_RECTANGLE sont effectivement remplies avec une couleur par défaut, ce qui efface ce qu'il y a en dessous.
Je ne vois qu'une solution pour ne pas effacer ce qu'il y a dessous, c'est de les tracer "à la main".
C'est à dire qu'au lieu de faire:

Code:

2D_RECTANGLE X1,Y1,X2,Y2

Il faut faire:

Code:

2D_POLY_FROM X1,Y1
2D_POLY_TO X2,Y1
2D_POLY_TO X2,Y2
2D_POLY_TO X1,Y2
2D_POLY_TO X1,Y1

Et pour un cercle, il faut tracer les segments correspondants.
C'est à dire qu'au lieu de faire:

Code:

2D_CIRCLE X,Y,R

Il faut faire:

Code:

2D_POLY_FROM X,Y+R
FOR I=0 to 6.284 STEP 0.02
2D_POLY_TO X+R*SIN(I),Y+R*COS(I)
NEXT I

6.284 vaut environ 2 PI, et la valeur du STEP donne la "finesse" du tracé, car elle correspond à la longueur d'un segment élémentaire. Ces valeurs peuvent être "réglées" suivant l'effet à obtenir.

Concernant les fichiers, les mots-clés EOF et SEEK seraient évidemment un plus.

Il n'y a pas de possibilité de sortie de boucle, mais encore une fois, pourquoi pas? EXIT_FOR et EXIT_SUB enrichiraient le langage et je suis preneur de toute suggestion.

Pour le moment, j'ai implémenté et testé 3 nouvelles commandes:
- PRINT_LOCATE X,Y pour que le prochain PRINT se fasse en (X,Y) de l'objet "cible des impressions", c'est à dire soit l'objet numéro 0 (la feuille FORM0), soit l'objet N si on a fait PRINT_TARGET_IS N
- PRINT_X_LOCATE X pour fixer la coordonnée X du prochain PRINT
- PRINT_Y_LOCATE Y pour fixer la coordonnée Y du prochain PRINT
Quand j'aurai créé les fiches du manuel de référence et que j'aurai décrit ces commandes dans le guide utilisateur, je mettrai une nouvelle version en téléchargement.

Pour les figures j'avais bien pensé à cette solution, c'est plus lourd, mais ça a le mérite d'être possible.
Pour le Print, ok, j'attends l'implémentation.

Autre chose, est-il prévu de pouvoir récupérer des paramètres dans l'exécutable compilé, pour le cas où il serait lancé en ligne de commande, directement ou par un .BAT par exemple ?

Merci en tout cas pour la réactivité.

Incidemment, il y a une manière plus élégante d'exprimer PI:
pi = 4*ATN(1)
J'ai essayé le cercle transparent avec votre méthode, c'est un peu plus lourd à écrire mais le résultat est tout à fait satisfaisant.

Pouvoir récupérer des paramètres dans l'exécutable est une nouvelle exellente idée. Je vais regarder cela.

Je pense par exemple créer une variable système:
PARAM_NUMBER dont la valeur est le nombre de paramètres passés à l'exécutable, et valant 0 s'il n'y a aucun paramètre,

et une fonction:
PARAM(I) qui retourne le Ième paramètre passé à l'exécutable.

Ce serait effectivement une solution idéale !

Une nouvelle version comportant les commandes PRINT_LOCATE, PRINT_X_LOCATE et PRINT_Y_LOCATE est disponible au téléchargement.
Voir la rubrique "Nouvelles Versions" pour plus de détails.

Testé, ça marche, impeccable !
Merci

Je viens de mettre à disposition une nouvelle version de PANORAMIC_IDE et de PANORAMIC_EDITOR qui permet d'exploiter les paramètres qu'on passe à un exécutable.

PARAM_NUMBER retourne le nombre de paramètres passés à l'application lors de son appel.
PARAM_VALUE$(N) retourne le Nème paramètre passé à l'application lors de son appel.

C'est à dire que lorsque vous générez un exécutable, et que cet exécutable est appelé en ligne de commande avec des paramètres, il est possible de connaître le nombre de paramètres ainsi que la valeur de chacun d'entre eux.

Exactement ce que je désirais, merci.

Autre chose (je devrais peut-être plutôt créer un autre topic), qu'y a-t-il d'erroné dans ce qui suit:

Code:

dim xs%,ys%
FORM 1
PRINT_TARGET_IS 1
PRINT "Ceci est une Form"

REPEAT
UNTIL MOUSE_LEFT_DOWN(1) = 1: Rem attente clic gauche
REPEAT
UNTIL MOUSE_LEFT_UP(1) = 1: Rem attente relâchement bouton
xs% = MOUSE_X_LEFT_UP(1)
ys% = MOUSE_Y_LEFT_UP(1)
PRINT STR$(xs%)
PRINT STR$(ys%)
END

le PRINT ne se fait pas et ça semble boucler quelque part, quoi que je fasse, je suis obligé de stopper sauvagement.
(le PRINT se fait normalement si j'enlève les instructions relatives à la souris).

Bravo, vous avez mis le doigt sur un "bug" !
Voici ce qui se passe:
Les 2 boucles REPEAT / UNTIL sont tellement courtes (en fait, le corps de ces boucles est vide, puisqu'elles ne comportent que la condition de rebouclage) qu'il n'y a aucune pause entre le début de la boucle et le test de rebouclage.
Cela fait que Windows n'a pas le temps de traiter l'événement "click gauche de la souris" et que PANORAMIC ne "voit" pas cet événement, et donc reboucle indéfiniment.

Cela va être corrigé dans la prochaine version: juste après un REPEAT, je vais forcer Windows à traiter les différents événements qui sont arrivés pendant l'exécution de la boucle. De même, après un END_WHILE, il y aura le même type de traitement des événements (puisque le même problème se présente dans la boucle WHILE condition / END_WHILE).

Pour le moment, je vous propose de forcer Windows à traiter les événements avec la commande DISPLAY:

Code:

dim xs%,ys%
FORM 1
PRINT_TARGET_IS 1
PRINT "Ceci est une Form"
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_DOWN(1) = 1: Rem attente clic gauche
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_UP(1) = 1: Rem attente relâchement bouton
xs% = MOUSE_X_LEFT_UP(1)
ys% = MOUSE_Y_LEFT_UP(1)
PRINT STR$(xs%)
PRINT STR$(ys%)
END

Cette commande DISPLAY est conseillée pour remettre à jour l'écran après un dessin ou une modification d'un SCENE3D, et peut s'appliquer dans ce cas précis, puisqu'elle effectue une pause dans l'application en redonnant la main à Windows.

Encore autre chose, mais je pense que vous l'avez lu dans la documentation:
il n'est pas nécessaire de créer un FORM pour effectuer ce test, puisqu'un FORM (de numéro 0) est implicitement créé au démarrage de l'application.
Le code peut donc se simplifier en:

Code:

dim xs%,ys%
PRINT "Ceci est une Form"
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_DOWN(0) = 1: Rem attente clic gauche
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_UP(0) = 1: Rem attente relâchement bouton
xs% = MOUSE_X_LEFT_UP(0)
ys% = MOUSE_Y_LEFT_UP(0)
PRINT STR$(xs%)
PRINT STR$(ys%)
END

C'est évident... une fois qu'on le sait ! Merci pour la suggestion qui me permet de poursuivre mes investigations...

Voici mon petit programme de tests modifié:

Code:

Rem Tstmous.bas
PICTURE 1
WIDTH 1,800
HEIGHT 1,600

Rem tracé d'une grille sur une image et clic sur une zone
Rem de l'image (pour simplifier on affichera un rectangle)
dim w%, h%, nc%, nr%, wc%, hr%, i%, xs%, ys%
w% = 640: h% = 480: Rem dimensions de l'image, en pixels
nc% = 10: nr% = 5: Rem nombre de colonnes et de rangées
wc% = w%/nc%: Rem largeur d'une colonne
hr% = h%/nr%: Rem hauteur d'une rangée
2D_TARGET_IS 1
PRINT_TARGET_IS 1
2D_FILL_COLOR 0, 255, 255: Rem remplissage cyan
2D_RECTANGLE 0, 0, w%-1, h%-1
2D_PEN_WIDTH 2
2D_PEN_COLOR 255, 0, 0: Rem grille rouge
FOR i% = 1 TO nc%
  2D_LINE i%*wc%, 0, i%*wc%, h%-1
  PRINT_LOCATE i%*wc%-wc%/2, 5
  PRINT CHR$(64+i%)
NEXT i%
FOR i% = 1 TO nr%
  2D_LINE 0, i%*hr%, w%-1, i%*hr%
  PRINT_LOCATE 5, i%*hr%-hr%/2
  PRINT STR$(i%)
NEXT i%

Rem attente clic gauche souris
REPEAT
DISPLAY : Rem pour laisser le temps de voir l'événement souris
UNTIL MOUSE_LEFT_DOWN(1) = 1
Rem attente relâchement du clic
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_UP(1) = 1

xs% = MOUSE_X_LEFT_UP(1)
ys% = MOUSE_Y_LEFT_UP(1)
Rem affichage des coordonnées du clic
PRINT_LOCATE 10,20
PRINT "Clic dans la case "+CHR$(65+INT(xs%/wc%))+STR$(1+INT(ys%/hr%))
END

Pourquoi la PICTURE 1 créée garde-t-elle les dimensions implicites, malgré les directives WIDTH et HEIGHT qui sont sans effet ? ce qui tronque la figure (rectangle) dessinée dessus.

PS j'ai aussi édité mon premier post, désolé je mélange un peu tout.

Citation :

Pourquoi la PICTURE 1 créée garde-t-elle les dimensions implicites, malgré les directives WIDTH et HEIGHT qui sont sans effet ? ce qui tronque la figure (rectangle) dessinée dessus.

Je ne comprends pas trop ce que vous voulez dire.
Lorsque j'exécute votre code, il se déroule parfaitement, les commandes WIDTH et HEIGHT donne un résultat correct:
Un PICTURE de 800 sur 400 est créé, il est blanc par défaut.
Puis un RECTANGLE de couleur cyan de dimension 640 par 380 se crée puis est quadrillé par des lignes rouges d'épaisseur 2 pixels.

Je pense que vous parlez du FORM numéro 0 (la fenêtre de visualisation), qui reste à sa dimension standard, et qui ne permet pas de visualiser le PICTURE dans sa totalité.
Dans ce cas, il y a 2 possibilités:
- soit vous lui faites occuper tout l'écran par

Code:

FULL_SPACE 0

- soit vous lui donnez une taille légèrement supérieure au PICTURE par

Code:

width 0,850
height 0,650

Personnellement, je préfère la première solution.
Cela donne:

Code:

Rem Tstmous.bas
PICTURE 1

WIDTH 1,800
HEIGHT 1,600

FULL_SPACE 0: Rem donne tout l'espace disponible à la fenêtre de visualisation

Rem tracé d'une grille sur une image et clic sur une zone
Rem de l'image (pour simplifier on affichera un rectangle)
dim w%, h%, nc%, nr%, wc%, hr%, i%, xs%, ys%
w% = 640: h% = 480: Rem dimensions de l'image, en pixels
nc% = 10: nr% = 5: Rem nombre de colonnes et de rangées
wc% = w%/nc%: Rem largeur d'une colonne
hr% = h%/nr%: Rem hauteur d'une rangée
2D_TARGET_IS 1
PRINT_TARGET_IS 1
2D_FILL_COLOR 0, 255, 255: Rem remplissage cyan
2D_RECTANGLE 0, 0, w%-1, h%-1
2D_PEN_WIDTH 2
2D_PEN_COLOR 255, 0, 0: Rem grille rouge
FOR i% = 1 TO nc%
2D_LINE i%*wc%, 0, i%*wc%, h%-1
PRINT_LOCATE i%*wc%-wc%/2, 5
PRINT CHR$(64+i%)
NEXT i%
FOR i% = 1 TO nr%
2D_LINE 0, i%*hr%, w%-1, i%*hr%
PRINT_LOCATE 5, i%*hr%-hr%/2
PRINT STR$(i%)
NEXT i%

Rem attente clic gauche souris
REPEAT
DISPLAY : Rem pour laisser le temps de voir l'événement souris
UNTIL MOUSE_LEFT_DOWN(1) = 1
Rem attente relâchement du clic
REPEAT
DISPLAY
UNTIL MOUSE_LEFT_UP(1) = 1

xs% = MOUSE_X_LEFT_UP(1)
ys% = MOUSE_Y_LEFT_UP(1)
Rem affichage des coordonnées du clic
PRINT_LOCATE 10,20
PRINT "Clic dans la case "+CHR$(65+INT(xs%/wc%))+STR$(1+INT(ys%/hr%))
END

Les limitations dont vous parlez dans votre premier post (nombre de variables, nombre de labels, taille des tableaux) sont, je le reconnais, peut-être un peu trop dures.
Elles ont été faites récemment et bon nombre d'exemples ne fonctionnent plus avec les dernières versions...

En effet, il y a quelques semaines, ces contraintes étaient beaucoup moins dures, mais les versions étaient limitées dans le temps pour obliger les utilisateurs à revenir télécharger une nouvelle version afin qu'ils utilisent à chaque fois un "meilleur" logiciel. Cela gênait beaucoup de monde.

Je vais réfléchir à la meilleure façon pour "obliger" les utilisateurs à avoir une version récente.
Je pensais relâcher peu à peu ces contraintes au fur et à mesure que le logiciel s'améliore, afin que les personnes intéressées reviennent télécharger souvent une nouvelle version.

En tout cas, pour la prochaine version, je vais assouplir ces limites afin de faire au moins "tourner" tous les exemples proposés.

C'est effectivement ce qui se passait, je ne voyais pas la totalité du PICTURE (j'oubliais le FORM 0). Avec le FULL_SPACE 0 je vois tout, donc (faux) problème réglé.
Je peux ajouter dessous un bouton pour la sortie.

Pour les limitations c'est donc une volonté délibérée et non une contrainte structurelle, je préfère ça et j'en comprends la motivation.
La limitation dans le temps ça n'est pas terrible non plus... pas facile de trouver la bonne solution.

jaimerai faire un dictionnaire ou un album de mes photos plus tard

le problème sai la limitation des ligne de code par fichier .exe environ 830 lignes est-il possible davoir dans une version qui contiendrai des milliers de lignes codes

jaime bien tout mettre dans un seul fichier sai tellement plu simple, comme le fichier panoramic
merci

Faire un album photos avec PANORAMIC est tout à fait possible.
Il n'y a AUCUNE limitation dans le nombre de lignes du code source. Je ne comprends pas la limitation à 830 lignes dont tu parles, et de plus, dans un fichier EXE.
Pour mettre dans un exécutable tous les fichiers externes qui sont appelés dans le source, il suffit de mettre tous ces fichiers dans le même répertoire que ton source et de créer une application (dans le menu Fichier).
Dans ce cas, l'exécutable produit contiendra les fichiers appelés (fichiers textes et images), mais sera très gros.
Les fichiers photos devront être au format BMP pour être inclus dans l'exécutable : pour le moment, seuls les fichiers TXT et BMP sont inclus dans une application.

je suis nouveau, je pense que je me suis mal esprimé désolé, je sais pour les BMP + TXT je peu on mettre comme je veu pas de problème, mes avant de convertir en exe je veux mettre pluss de code ligne dans mon ficher principal, mes code son pas des BMP ni des TXT ma limite de ligne va pas plus loin que environ 830

Je comprends que tu ne peux pas mettre plus de 830 lignes environ dans ton source.
Mais, je n'ai pas mis de limite au nombre de lignes du source. S'il y a une limite, je vais regarder pourquoi et le corriger.
Je te tiens au courant.

Avec PANORAMIC_EDITOR, j'ai fait un fichier source d'environ 5000 lignes:
2500 fois la séquence

Code:

v%=v%+1
print v%

avec toutes les 25 séquences, une commande CLS pour effacer les impressions sur la fenêtre et par conséquent pour recommencer à imprimer à partir du haut de la fenêtre.

Il n'y a aucun problème pour lire, enregistrer ce source, l'exécuter et créer un exécutable.

Je le répète : il n'y a pas de limitation au nombre de lignes du code source.
Je suis maintenant sûr que PANORAMIC fonctionne avec 5000 lignes de source et je pense qu'il fonctionne avec bien plus de lignes.

moi javais utilisé des ligne de print "" avec 100 lettre de a par ligne

peut-être mon exemple nétai pas bon

cette exemple je lavais utilisé dans liberty basic je me suis rendu a 26,900 ligne de code avec des print "" jaurai pu allez plus loin

Eh bien, je veux bien utiliser ton exemple.
Je comprends que tu fais des lignes constituées de:

Code:

print "":print "":print "": - - etc - - :print ""

Je vais tester ...

jutilise blender pour la 3d, je suis obliger de convertir le fichier (exemple.dxf)

pour le mettre dans le format (exemple.md2)

sais pas un gros problème

je me demande si sa serait possible pour panoramic dutiliser se format
aussi (.dxf)


merci A+

PANORAMIC utilise aussi l'un des formats 3D les plus répandus : le format 3DS, c'est à dire le format créé par 3D Studio MAX et utilisé par la plupart des modeleurs 3D.
Mais le format DXF est lui aussi très utilisé. Bien que ce ne soit pas l'une de mes priorités, l'utilisation de ce format pourrait être envisagée dans le futur.