Utilitaire Designer: générer une structure Panoramic valide

J'ai mis sur mon site, dans la rubrique Panoramic, deuxième page, cet urilitaire Designer qui permet de générer une structure Panoramic valide, dans un fichier *.bas. Le programme est multi-lingue (anglais, français et allemand), et il y a un programme exemple dans la distribution. Le programme contient aussi une documentation en ligne simple.

Bonjour Klaus,

Intéressant ton programme...
Pourquoi tu ne chercherais pas à l'intégrer dans ton EDI/IDE ?
Bref, avant de poser cette question, j'ai voulu récupérer sur ton site l'IDE/EDI pour me le remettre en mémoire,
mais le lien sur ton site semble être mort... je pose donc la question un peu dans le "vide"...


Concernant la sélection de la langue, à la place de ta routine init_langage qui me parait un peu figé,
tu pourrais avoir par exemple 3 fichiers de type texte composé de cette manière :

fr.lan :	de.lan :	an.lan :
' ---- Francais [0000] Fichiers [0001] Ouvrir... .. etc...	' ---- Allemand [0000] Dateien [0001] Öffnen...	' ---- Anglais [0000] File [0001] Load...

et tu charges par exemple, au lancement de designer le fichier an.lan
Cela permettrai de pouvoir créer/éditer facilement les champs (à partir du bloc-note) dans les différentes langues...

Hello Klaus,

Je me suis permis de modifier légèrement ton prog pour la gestion des langues...
si cela t'intéresse voir ici
C'est perfectible...

Le lien vers l'EDI est rétabli.

Le code généré de Panedi respecte les règles que j'ai appliqué au Designer. Les deux programmes attaquent le même problème par une approche différente:
- Panedi est destinée à une conception style WYSIWYG, un peu comme l'IDE de Panoramic, mais avec la possibilité de gérer le code complet d'une application par l'intermédiaire de Panedi. Le programme est enregistré dans un fichier de projet en format texte, mais qui n'a rien d'un fichier source *.BAS. Ce dernier doit être généré à partir de Panedi et n'est qu'un sous-produit.
- Designer est destiné à assurer une conception saine d'un programme Panoramic, en particulier pour les nouveaux-venus qui ont toujours un peu de mal à s'imprégner de la logique de gestion des évènements. Le résultat est un fichier source *.BAS qui pourra être exécuté et modifié dans l'éditeur Panoramic, mais qui peut aussi être repris dans le Designer, à condition de respecter le système de commentaires qui servent de guide en phase de chargement.

Pour le multi-langage dans Designer, je suis en train de réaliser un hybride entre la version actuelle et celle que tu proposes. Je place tous les morceaux de texte dans des commandes DATA, et je charge ma variable t$ par des READ. Et j'ajoute un bouton dans la fenêtre des options qui permet d'exporter ces textes sous forme d'un fichier Designer.ini. Au démarrage de Designer, si ce fichier existe, il sera lu au lieu des DATA, et le tour est joué. Cela permettra même d'ajouter des langages autres que ceux prévus actuellement.

Nos messages se sont croisés. Je vois que tu as fait le gros du travail déjà, et je vais le prendre tel qu'il est, mais je vais lui appliquer mon idée d'exporter les textes initiaux. Cependant, je ne ferai pas de bouton d'exportation, mais je vais exporter d'office si ces fichiers n'existent pas, et je vais créer un fichier supplémentaire contenant la liste des langages, ce qui permettra de configurer le combo du choix des langages. On pourra ainsi librement ajouter d'autres langages, et c'est ce que je voulais obtenir.

Bonjour Klaus,

1- Si tu pouvais obtenir la liste des fichiers ayant l'extension lng -> tu aurais le nb de langue définies.
2- Quand au combo, si dans la première ligne du fichier lng, tu as le libelle de la langue,(par ex. 'français' , 'Allemand', 'Anglais', 'Martien'), tu pourrais initialiser le combo de manière automatique... sans avoir à créer un autre fichier contenant la liste des langues. Tu pourrais avoir autant de langue que tu veux sans toucher une ligne de code.... (bon c'est vrai que le martien, à part jjn4, n'est pas très utilisé)



une autre idée qui pourrait être mise en oeuvre :
- Un fichier de config (type txt) que l'on charge dans une dlist qui contiendrai la langue par défaut, le dernier fichier ouvert, etc...

J'ai mis la version 1.05 en ligne ! Elle contient la gestion multi-langage proposée par Nardi26, avec un petit plus: il y a un fichier Designer.ini qui contient ceci:

Citation :

2
English,an.lng
Français,fr.lng
Deutsch,de.lng

LA première ligne est le numéro de la langue par défaut (ici, Français), les autres lignes donnent le libéllé de la langue et le nom du fichier texte pour la langue, séparés par une virgule.

Si ce fichier existe, les fichiers *.lnk correspondants sont censés exister. Toutes les langues notées dans ce fichier sont accessibles à la sélection, leur choix a un effet immédiat et perdure d'une session à l'autre.
Si ce fichier n'existe pas, il est créé comme ci-dessus, et les 3 fichiers indiqués sont créés automatiquement.
Ceci a l'aventage de pouvoir distribuer le programme seul, sans fichiers annexes. Les fichiers se créent dans le répertoire par défaut au lancement du programme.

On peut ajouter facilement une autre langue, dans la limite d'un total de 20 langues. Pour cela, il faut ajouter une ligne xxxxx,xx.lnk dans le fichier Designer.ini et créer le fichier xx.lng.

Le programme est en ligne sur mon site.

Klaus

quel écran utilises tu ?
chaque fois que j'ouvre une de tes créations il me faut retailler les forms
pour que cela rentre dans le 15"4 de mon portable.

je me souviens d'un post mais je ne sais plus où il est
on y parlait de la récup de la taille d'écran

perso, j'essaye de ne pas dépasser 800x600 pour les écrans les plus vieux

@ygeronimi :
Il est clair que pour ce qui concerne l'interface graphique, il serait peut être plus judicieux de définir la dimension des objets en % par rapport à l'écran (screen_x/screen_y)
mais cela alourdi considérablement le code !...

@Klaus:
Je vois dans le prog que tu as défini des "blocs" d'objets (label, dim, code) et que tu as déclaré autant de fct pour "agrandir" ou "rétrécir" ces blocs.
Pourquoi ne pas utiliser une fonction d'évènement plus globale en te basant sur number_click pour connaitre le "bloc" sur lequel tu dois faire le traitement ?
cela serait peut-être plus simple par la suite si tu souhaite rajouter un autre type...

Un truc dans le genre :

Code:

Redimensionner:
  expand = bin_xor(expand,1)
  si expand=1
    mémo =  Taille(bloc_cliqué)
    Taille(bloc_cliqué)=MAX
  sinon
    Taille(bloc_cliqué)=mémo
  finsi
retour

Serait-ce un embryon de "pseudo-fenêtre" ?

Si je me souviens bien , tu avais fait il y a quelques temps, un bout de programme qui permettais d'ouvrir une applic dans une zone bien défini (je crois que c'etait un notepad ou la calculatrice dans un formulaire...) il n'y a rien à gratter de ce coté là ?

@ygeronimo:
mon écran est 1280x800. Cela me semblait une résolution courante. Mais je vais réfléchir à une adaptation automatique. Les dimensions se récupèrent pa screen_x et screen_y, il y a donc moyen de le faire.

@Nardo26:
J'aime bien ton pseudo-code ! D'ailleurs, cela me donne une idée loufoque: et si Jack donnait la possibilité de changer les noms des mots-clé de Panoramic par une liste de mots choisi par l'utilisateur ? On aurait ainsi un Basic "français" bien sympathique... Il y a des langages qui font quelque chose de simulaire. Il suffit de regarder le W-langage dans Windev (PC-Soft) pour voir la grande lisibilité d'un programme de ce genre. Il est vrai qu'il utilise des mots-clé en français souvent très longs, qui a eux seuls sont une partie de la documentation...

Bon, blague à part. Mon programme changera, je suis en train de réfléchir à ajouter d'autres sections pour affiner ses fonctionnalités, et forcément, je reprendrai la présentation visuelle qui a "poussé" sans véritable concept de départ, m'ayant plutôt concentré sur la structure du résultat. Mais cela changera avec l'ajout de nouvelles sections, et la présentation sera plus rigoureuse. Je projette par exemple de gérer les GOTO et les labels autres que routines évènements et sous-programmes internes, afin de maîtriser le flux par rapport à l'intégrité des sous-programmes, et en particulier par rapport aux évènements. Cela passe par le placement contrôlé des labels dans le source, et la vérification de la destination par rapport à l'emplacement du GOTO. Et y a d'autres idées en train de germer...

D'ailleurs, soit dit en passant, je me suis heurté à un problème lié aux CONTAINER de Panoramic. On peut y placer beaucoup de choses, mais pas un autre CONTAINER ! Dommage. Mon pseudo-objet FRAME le fait... J'ai donc simulé un container général avec un picture, un rectangle et un print pour la caption de ce container simulé. Je reverrai tout cela pour produire un ensemble plus cohérent.

@ Klaus

Très juste j'ai déjà essayé mais c'est vrai container ne peut contenir un container.
(si seulement je pouvais me rappeler pourquoi j'ai voulu faire cà...... )

Une petite remarque concernant les CONTAINER
actuellement il existe une commande COMMAND_TARGET_IS qui ne fonctionne que sur les objets de type FORM. Ce qui serait intéressant c'est de pouvoir écrire :

Code:

CONTAINER 2
COMMAND_TARGET_IS 2
BUTTON 3:CAPTION 3,"Bouton 1" : ....
BUTTON 4:CAPTION 4,"Bouton 2" : ....
BUTTON 5:CAPTION 5,"Bouton 3" : ....

au lieu de :

Code:

CONTAINER 2
BUTTON 3:CAPTION 3,"Bouton 1" : ....
BUTTON 4:CAPTION 4,"Bouton 2" : ....
BUTTON 5:CAPTION 5,"Bouton 3" : ....
PARENT 3,2
PARENT 4,2
PARENT 5,2

Il est vrai qu' on ferait des économies d'écriture.

Très bonne idée que ce Designer. Je suis cela de près.

@Klaus:

Citation :

si Jack donnait la possibilité de changer les noms des mots-clé de Panoramic par une liste de mots choisi par l'utilisateur ? On aurait ainsi un Basic "français" bien sympathique...

C'est une idée que je prends très au sérieux et je l'avais déjà proposé en Août 2008:
https://panoramic.1fr1.net/t135-panoramique-un-basic-completement-francais
Et le pire, c'est que je l'ai fait. A l'époque, j'avais une version avec tous les mots-clés en français. Je ne l'ai jamais publié car cela intéressait peu les utilisateurs.

Il n'y a aucune raison qu'un CONTAINER ne puisse pas contenir de CONTAINER qui contienne lui-même un CONTAINER, etc.
La seule raison à cette interdiction est que je n'ai toujours pas codé un DELETE pour les objets d'un CONTAINER quand on DELETE ce CONTAINER. Je vais le faire d'autant plus que cela existe pour les SUB_MENU (procédure recursive de destruction des objets).

@Nardo26:
COMMAND_TARGET_IS sur un CONTAINER est tout à fait logique et faisable.

Cela prend une bonne tournure, et c'est de plus en plus cohérent.

Personnellement j'ai jamais été contre d'avoir des mot clés français, même j'aurai été le seul à l'époque à le dire. Par contre faut-il vraiment 2 versions, ne peut-on pas avoir double emploi de mots clés.

Moi ce qui m'intéresserais, est d'avoir la possibilité de déclarer des mots clés personnel, qui puissent avoir un appel. Depuis j'ai d'autres solutions, mais ce serait plus simple ces mots clés.

Mais il y en a d'autres qui pensent mieux que moi.

C'est clair que les mot-clés en français c'est sympa :
Quand je vois par exemple des listing écrits sous Omnis, c'est franchement agréable à lire!
Mais cela oblige Jack à maintenir 2 versions : Anglais / Français (sinon pour Severin et autres allemand, cela ne sera pas évident pour eux...)
Ou alors avoir un système de dictionnaire de langue (comme pour le prog designer) mais bonjour le boulot !!!

Perso, je n'ai rien contre mais bonjour pour ne pas faire de mélange entre les noms de variables, les labels et les mots clé.

je prends un exemple un peu idiot :

nous avons déjà un mot clé en français : Date$
et pour moi c'est un petit casse tête quand je veux créer une variable string date pour lui donner un nom.

Je vous laisse méditer là dessus....

@Jack:
J'ai été très heureux de lire ton message. Je trouve ta réaction concernant les mots-clé en français très encourageante. J'ai utilisé (et j'utilise encore) Windev avec son fabuleux W-langage, et la première surprise passée, j'ai trouvé cela très agréable. Je pense, et surtout si le choix du langage peut être fait par l'utilisateur, par le biais d'un menu de configuration par exemple, que cela apporterait un vrai plus à Panoramic.

Et savoir que bientôt la restriction d'un Container dans un Container pourrait être levée - alors là, c'est super. D'ailleurs, la suppression des éléments contenus ne marche pas seulement pour un menu ou sous-menu, mais aussi pour une form dont les objets sont automatiquement détruits lorsqu'on détruit la form, et leur numéro est réutilisable.

L'objet container est très utile. Je m'en sers avec Designer, non seulement pour regrouper graphiquement certains objets, mais aussi pour pouvoir les cacher ou montrer en block, les déplacer en block, etc. C'est un excellent ajout à Panoramic, et je commence à m'en servir pour simuler une form modale (quand on ouvre une form "modale", on devrait pourvoir agir sur les objets de la form modale, mais pas sur les autres objets, jusqu'à ce qu'on ferme la form modale): il suffit d'avoir un container global qui englobe tous les objets de la form 0, plus un container par form modale simulée. On désactive alors le container de base et on montre le container simulant la form modale, et on obtient exactement cela: être obligé de traiter la form modale (le container en réalité) sans pouvoir cliquer ailleurs. Voici une démo. Le bouton "Saisir" affiche une form simulée, et on ne peut travailler qu'avec ses objets. Son bouton "Valider" referme cette "form", et la form initiale redevient accessible. On peut bien sûr avoir autant de "forms modales simulées" que nécessaire. Voici le code:

Code:

label exit, valider, saisir
width 0,620 : height 0,440
container 1 : width 1,600 : height 1,400 : caption 1,"Ecran de base"
container 2 : width 2,300 : height 2,100 : top 2,100 : left 2,50 : caption 2,"Saisie"
hide 2

button 11 : parent 11,1 : top 11,20 : left 11,10 : caption 11,"Saisir" : on_click 11,saisir
button 12 : parent 12,1 : top 12,300 : left 12,20 : caption 12,"Sortir" : on_click 12,exit
alpha 21 : parent 21,2 : top 21,20 : left 21,10 : caption 21,"Valeur:"
edit 22 : parent 22,2 : top 22,20 : left 22,80
button 23 : parent 23,2 : top 23,50 : left 23,10 : caption 23,"Valider" : on_click 23,valider
end

exit:
terminate

saisir:
inactive 1
show 2
return

valider:
hide 2
active 1
message "On a saisi: "+text$(22)
return

A cette occasion, une petite suggestion: tout comme la commande COMMAND_TARGET_IS a un sens pour un CONTAINER, pourrait-on avoir la commande COLOR et FILE_LOAD avec cet objet ?

Msieur Klaus

J'ai voulu telecharger Panedi avec les nouveautés et gros bug
Décompression Panedi.Icones.bas
puis bug si je lance

(102)Impossible to create directory. line 1611

Mise à part que moi, form modale je ne comprend pas bien, J'ai eu exactement la même idée dans l'un de mes programme en cours.

Le seul dommage, est qu'on ne peut pas mettre une couleur sur un container, et c'est bien dommage. j'aurai aimé dans mon programme, avoir des couleurs différentes qui auraient été en rapport avec "boutons picture maison"., et de ce faite une meilleurs compréhension entre les boutons et le container visible.

@ygeronimi:
dans la dernière distribution, il n'y a plus "panedi icones.bas" - il n'y a plus que panedi.bas.

Recharge la dernière version et réinstalle, en plaçant bien les deux répertoire fournis. Si tu exécutes à partir de l'éditeur, il faut placer le répertoire Panedi_modeles dans le répertoire de l'éditeur. Si tu crées un Panedi.exe, il faut placer le répertoire Panedi_modèles dans le répertoire où se trouve Panedi.exe. Alros, ça devrait marcher.

Pourrais-tu mettre les messages qui concernent Panedi dans le fil de discussion corresponant:
https://panoramic.1fr1.net/t842-edi-realise-entierement-en-panoramic
Ce serait plus logique.

@Cosmos70:
Le terme "form modale" vient directement de Delphi, mais c'est un terme utilisé de manière générale avec les programmes Windows.

Il y a deux façons d'ouvrir une nouvelle fenêtre:
La première est celle que Panoramic utlilise quand on fait FORM N. La fenêtre Windows s'ouvre, mais la ou les autres fenêtres restent actives, on peut cliquer dessus ce qui fait disparaître la nouvelle fenêtre ou la passe en arrière-plan, etc. C'est particulièrement gênant quand on veut utiliser cette fenêtre pour saisir des informations et on doit attendre la validation avant de continuer. Ce mode s'appelle "non-modal". C'est aux fenêtres ce que la commande EXECUTE fait aux programmes.
La seconde est celle que Panoramic utilise dans toutes les fenêrtes message_xxx ou celles ouvertes par file_name$. Tant qu'on n'a pas validé ou fermé cette fenêtre, on ne peut tout simplement pas cliquer ailleurs dans l'application. Ce mode est appelé "modal". C'est aux fenêtres ce que la commande EXECUTE_WAIT fait aux programmes.

En fait, il manque une commande FORM_MODAL en Panoramic - ce serait évidemment le pied !

Merci Klaus,

au moins je saurais maintenant.
La forme modale que je peux employer le mot maintenant, je l'avais déjà demandé, il y a plus de 6 mois.
J'avais remarqué je crois dans une pharmacie une nouvelle fenêtre qui affichait en gros le prix réclamé, et la fenêtre restait au 1er plan. Je trouvais dommage de ne pas avoir cette possibilité avec Panoramic.

La seule méthode alors (avant les container) que j'avais trouvé, était de définir un mémo , le mettre en "sur-impression sur les autres objets" et défini à la fin des déclarations d'objets, le mettre à hide, et de le montrer le moment venu.

Peut-être arriverons nous à l'obtenir. Ceci dit maintenant ta dll qui met les fenêtres ou non au premier plan, résoud le problème.

C'est vrai, mais avec les moyens seuls de Panoramic, on peut aussi obtenir quelque chose de semblable. Essaie le code de mon post précdédent...

Hello Klaus !

On a un peu dérivé sur le sujet de ce post...

Tu en es où dans ton programme Designer ?

Citation :

Je projette par exemple de gérer les GOTO et les labels autres que routines évènements et sous-programmes internes, afin de maîtriser le flux par rapport à l'intégrité des sous-programmes, et en particulier par rapport aux évènements. Cela passe par le placement contrôlé des labels dans le source, et la vérification de la destination par rapport à l'emplacement du GOTO. Et y a d'autres idées en train de germer...

Ça progresse ?