compréhension du langage

Je reprend ici la discution que j'ai eu avec Klaus dans :
https://panoramic.1fr1.net/t1367-fehlermeldung-von-windows7#11752

Je pense que ce serait bien que chacun d'entre nous dise comment il a compris la programmation objet

C'est vrai que l'aide qui accompagne ce langage est complète.
Mais pour tout ceux qui sortent du basic classique, le langage objet est difficile à assimiler. J'en ai fait l'expérience avec Justbasic, et ce langage serait même un intermédiaire entre le basic traditionnel et Panoramic.

Déjà là je ne comprenais rien. J'avais acheté il y a 10 ans le livre Le Starter , Programmation Basic avec Liberty Basic, qui comprenais le cd du basic. En faite ce basic était en construction, ainsi par exemple, la fonction racine carré n'était pas disponible: racine carré de 9: a=9^0.5 soit mettre la puissance à 1/2.
Je suis resté longtemps sans programmer par incompréhension. Par exemple je ne comprenais pas comment on remplissait une liste. En écrivant dans une liste, cela ne servait à rien.
Je vais donné un exemple de programme basic selon Justbasic et Lyberty basic à ses début, ensuite lyb.. étant payant, je ne peux rien dire.
' afficher un bouton qui a une image en position 50,30 du coin supérieur gauche UL
BMPBUTTON #graph , Bip ,[bip], UL, 50 ,30
' ouvrir une fenêtre windows
OPEN "BUTTON" FOR graphics AS #graph
PRINT #graph, " Instruction BUTTON"
[boucle]
INPUT a$
GOTO [boucle]

[bip]
BEEP
CLOSE #graph
END

Dans cette exemple, on reboucle continuellement à boucle. L'instruction INPUT a pour fonction de stopper le programme. Lorsque qu'on clique sur le bouton, le programme se branche à bip.

Des exemples avec goto boucle, il y en a beaucoup avec Justbasic., Ensuite, j'ai vu des exemples avec "WAIT"
Au lieu de mettre INPUT, et reboucler avec un goto, il y a eu une étiquette, les instructions et terminé par WAIT, à la place de GOTO [boucle]

Cela ressemblait davantage à du évènementiel et s'approchait de Panoramic.
Je ferme la parenthèse avec Justbasic.
Lorsque je suis arrivé à Panoramic, il me semble que cela m'a paru plus simple. Le gros problème est "END", et je pense que je ne suis pas tout seul, vu que même que ceux qui était là avant moi, avait aussi des problèmes de compréhension avec cette instruction. J'ai pu constaté que dans le courant de 2010, certain d'entre nous avait encore des doutes.

Je dois dire que cette instruction est à mon avis mal nommée. Tout ceux qui ont programmé en basic avant se sont posés des questions. WAIT en Justbasic est mieux nommé, car lorsqu'on arrive en fin de sous programme, on arrête à WAIT. qui est une instruction d'attente.

Ensuite il y a la notion de sous programme. On peut se poser des questions: est-ce un sous programme?. On pourrait considérer que le clique sur un objet nous envoi sue un micro programme, une direction comme le fait select case. De là on se sert de tel ou tel sous programme qui se termine par return. Je fais cette distinction en constatant que Justbasic à ce type de codage: WAIT et RETURN

Je pense qu'il serait bon, en dehors de l'aide d'avoir un livret de départ qui montre bien le fonctionnement de Panoramic. Selon qu'on commence à programmer, ou que l'on vienne d'un autre langage, chacun a des habitudes, des idées, des préjugés différents selon ses connaissances.

C'est tellement vrai, qu'il m'a fallu plus d'un an pour m'apercevoir que END pouvait être utilisé à plusieurs endroit, et servir à autre chose.
Lorsque ces derniers temps, j'ai conçu mon débogueur, je me suis encore posé des questions, et là je peux dire que le mot end a tout son sens. UN OBJET QUI EST DÉCLARÉ APRÊS LE END N'EST PAS EVENNEMENTIEl! J'ai du modifier mon débogueur à cause de cela. Les clics sur les checks ne servaient à rien. Mon débogueur fonctionnait, mais modifier les testes me posaient des gros problèmes que je ne comprenais pas, et j’imputais cela à des bugs de Panoramic.

Je suis persuadé que des dysfonctionnement de Panoramic, sont en fait une mauvaise interprétation de la méthode Panoramic. Panoramic est bien conçu, mais malgré les différentes aides, la méthode n'est pas assez expliquée. Pendant plus d'un an et demi, je n'ai pas arrêté de faire des testes, au cours des programmations, pour savoir si on pouvait faire tel ou tel chose. Si c'est le cas, c'est bien qu'il y a un manque.

Maintenant la compréhension de Panoramic par les autres intervenant, serait la bien venu, pour bien comprendre les problèmes des nouveaux Panoramiciens. On reçoit bien souvent des programmes qu'il faut analyser et qui sont mal conçus parce que la méthode mal comprise.

Salut Cosmos,

Hé oui, c'est l'eternel problème qui revient. Je mets ici ma façon de stucturer un code en Panoramic, mais attention c'est pas forcement valable pour la 2D et 3D

Quant à END je me suis imposé dans ma tête de penser "FIN DE LA MISE EN PLACE" plutot que END.
Je propose de créer END_START ou autres noms.......

Pour GOTO j'ai mis en exemple la bonne façon de l'utiliser selon moi. C'est pas pour toi, Cosmos, vu que tu connais dèja tout çà.

Placez cet exemple dans l'éditeur pour avoir la coloration, c'est plus parlant.

Code:

' Exemple de ma façon de structurer un code_source PANORAMIC

' Déclaration des LABEL(s) et DIM(s)
DIM a$,b$
LABEL start,start2,fin

'================ FORM 0
' Mise en place éventuel d'un MAIN_MENU pour FORM 0
width 0,500:height 0,500: ' top et left......
hide 0:' pour interdire de commencer à saisir avant que PANORAMIC est terminé sa mise en place
on_close 0,fin:' (ou ON_CLICK 0)
memo 1:' ..........

' =============== FORM 10
' et autres FORM(s) ou objets
' Mise en place éventuel d'un MAIN_MENU pour FORM 10
Form 10:command_target_is 10
' Déclaration des objets pour FORM 10 avec leur taille et position
' une remarque la taille et la position des objets peuvent être definies après END
button 11:top 11,10:left 11,10

' autres FORM(s) ou objets

' =============== Diverses actions AVANT END
' chargement de fichier ou autres actions
file_load 1,"image.bmp": ' par exemple
dlist 90:' pour travailler un fichier par exemple
control_truc=1: 'initialisation de variables
' ============= START
show 0:gosub start:' pour commencer
' et enfin
END: ' ICI JE PENSE "fin de la mise en place" mais pas fin tout court
' c'est vrai que END aurait du s'appeler autrement (END_START par exemple)

' ============== LE PROGRAMME
start:
' ......

start2:
' ......
if control_truc=0 then goto sart2
' ......
return

' Autres LABEL(s) déclarés

fin:
terminate

A+

Salut jean Claude,
En y réfléchissant, je crois qu'il faudrait un tutoriel.
On a une aide, un manuel, des conseils. C'est très bien , et même très bien fait.
Seulement, lorsqu'on programme sur un nouveau langage,, on regarde, et on se dit, "je vais commencer par quoi?"

Je pense qu'un tutoriel, aurait un avantage de bien commencer par un point de départ, de voir chaque étape, et de faire une progression.

Je ...
Je dois quitter, à vous!

Je viens de voir le problème de Severin sur Programm Strüktur, et je laisserai à un polyglote de répondre, les traductions sont tellement marantes parfois.

Je constate en regardant la traduction que le sujet ici prend tout son sens. L'instruction END pose réellement un problème à la majorité des nouveaux inscrits.

Il va être temps de faire un tutoriel, vous ne pensez pas?

Je suis complètement en accord avec toi Cosmos, mais je pense que Jack n'a vraiment pas le temps.
Quoiqu'il faudrait se poser la question de savoir si cet état de chose ne nuit pas à PANORAMIC au bout du compte.

A moins de trouver des volontaires pour le faire ce tuto .....

A+

Quand dans l'EDITEUR ou l'IDE, on fait : Aide / Conseils, la première rubrique est :
1.1 - Quelle est la structure d'un programme ?
et on y trouve:

Citation :

La structure conseillée d'un programme est la suivante :

1 - Déclaration : LABEL et DIM

2 - Programme principal : définition des composants (objets), calculs, comportement, END

3 - Traitement d'événements

Exemple : création d'un bouton qui affiche "Cliquez sur moi", puis "Salut!" quand on a cliqué sur lui.

rem déclaration des étiquettes utilisées
LABEL clk

rem déclaration des variables utilisées
DIM A$

rem --- PROGRAMME PRINCIPAL ---
A$ = "Cliquez sur moi"
rem création d'un OBJET
button 1
rem lui donner un petit texte (son "intitulé")
caption 1,a$
rem définir le traitement quand il est cliqué
on_click 1,clk

rem --- FIN DU PROGRAMME PRINCIPAL ---
end

rem --- TRAITEMENT DES ÉVÉNEMENTS---
Clk :
caption 1,"Salut!"
return

Pourquoi structure "conseillée" ?
C'est parce que le langage Basic n'est pas un langage structuré Il n'y a pas la notion de bloc comme en C/C++ avec { } ou en Pascal avec BEGIN / END, ou de procédure ou de fonctions.
La seule notion de bloc est la suite des instructions qu'on met dans les boucles REPEAT / UNTIL ou WHILE / END_WHILE ou dans le test IF / END_IF ou IF / ELSE / END_IF.
Et donc on ne peut pas imposer une structure de programme, mais seulement conseiller une structure pour éviter des problèmes.

Il faut voir les choses autrement:
1 - L'écriture d'un programme est libre et il n'y a pas vraiment de structure de programme à respecter.
2 - Par contre il y a quelques règles à respecter.

Les règles à respecter sont:
- on ne peut pas exécuter un RETURN s'il n'y a pas eu de GOSUB préalable.
- tout sous-programme appelé par GOSUB doit exécuter un RETURN.
- quand le sous-programme appelé par GOSUB a exécuté un RETURN, l'exécution revient juste après le GOSUB appelant.
- le traitement d'un événement doit se terminer par l'exécution d'un RETURN.

Ce qu'il faut avoir compris, c'est que dans le cas de l'appel d'un sous-programme de traitement dun événement, le RETURN ne renvoie pas à un emplacement dans un programme, car il n'y a pas eu de GOSUB. Le RETURN marque la fin du traitement d'événement, et permet de passer au traitement de l'événement suivant, s'il y en a eu un.

Le END ne sert qu'à arrêter le déroulement du programme pour éviter d'aller exécuter des sous-programmes qu'on place en général après. C'est tout. Lorsqu'un END a été exécuté, les événements qui ont été déclenchés peuvent alors s'exécuter.
En général, un programme configure son interface (création des objets, déclaration des événements) puis exécute un END.
C'est le cas dans l'exemple plus haut: s'il n'y avait pas de END, comme l'exécution s'effectue en séquence, il s'afficherait ,"Salut!" sur le bouton, et à l'éxécution de RETURN, il y aurait une erreur.

Si certaines personnes se posent ces questions fondamentales sur le rôle des événements, sur le type de programmation (linéaire/événementielle), sur la structure d'un programme, sur le rôle de END, c'est que le développement de PANORAMIC a été trop rapide (augmenter le nombre de mots-clés a été la priorité) et que le côté tutoriel, apprentissage et pédagogie a été laissé un peu de côté.
Sur le site, il y a des tutoriels en construction depuis des années... C'est un indice.
Mais je ne peux pas tout faire...

@ Jack

Je ne sais pourquoi certain ce sont posé la question mais pour moi
qui ne sort ni d'une ecole d'informatique ni de polytechnique mais avec mon petit bepa
je peus t'assurer que Panoramic son language et surtout ses aides sont une bénédiction.
j'adore créer et l'informatique était pour moi "le monde de l'obscure" jusqu'il ya quelque temps.
Aujourd'hui je trouve avec Panoramic un log qui :
- évolue en fonction des besoins de chacun et pas tous les x mois
- est compréhensible par mon petit cerveau
- qui est suivi au jour le jour par son auteur et pas quand une boite a besoin de fric
- un forum hyper sympath où l'entraide est devenu une religion et polyglote

enfin je vois le sujet comme la terrible question :

"To be or not to be"

Perso je n'ai pas ce type de problème le seul Pb dans mes conceptions c de retrouver mes variables.
je suis bordelique et au bout 500 lignes j'arrive plus à me souvenir de leurs noms.

Non, le développement n'a pas été trop rapide, Cosmos70 et moi-même nous avons pensés aux nouveaux arrivants, et surtout à ceux qui viennent du basic.

Merci pour ton intervention qui clarifie une nouvelle fois les choses. Pour ma part j'ai bien assimilée la différence entre Séquentiel et Basic.

A+

PS ce message était destiné à Jack. Yeronimi on s'est croisé.

Merci Jack de répondre.
Mais à mon sens tu n'es pas concerné. Le travail que tu as fait est très bien. La preuve, est le résultat des différents programme que l'on publie.

Seulement chaque fois que nouveau "élu" arrive, il a du mal à assimiler la méthode alors que tu as tout mis.

Donc je pense que si on fabriquait un tutoriel avec des exemples, les nouveaux venus comprendrait mieux le fonctionnement de Panoramic.

Le problème est que chacun qui opte pour ce langage, regarde les choses dans le désordre, et la structure il ne la comprend pas tout de suite.

En commençant par Justbasic, je voyais mal le fonctionnement d'un système objet (je parle de mon expérience, vu que celle des autres, je ne la connais pas). Habitué au basic commun qu'on a tous fait, comment cela s'exécute?. Les lignes de programme s'arrètent. Encore faut-il comprendre pour ainsi dire qu'une partie du programme est fini.
C'est par l'appui sur un objet que le programme est relancé dans une autre direction, mais cela, il faut le comprendre.

Je me suis rendu compte qu'un tutoriel était plus parlant, et généralement, lorsqu'on voit que celui-ci existe, c'est par cela qu'on commence. Donc pourquoi pas!

Combien de fois devons-nous intervenir, et encore, c'est surtout Klaus qui s'y colle le plus, pour faire comprendre le truc qui fonctionne.

Et maintenant ton basic devient international! Parmi les nouveaux on a un Portugais, et des Allemands.
Si on construit un programme simple au départ, que l'on explique, et on augmente les difficultés en rajoutant au fur et à mesure les lignes, même en ne comprenant pas la langue, le système Panoramic est tellement simple par rapport aux autres langages qu'il sera vite compris. Il n'y a que END qui pose problème pour tout ceux qui commence. il y a confusion avec le END habituel, qui fait sortir du programme. Regarde la réaction de Séverin (si la traduction est bonne, et que j'ai bien compris) sur ce mot.

Je dis cela comme ça (celà ne me concerne pas, et ça m'est égal), peut-être faudrait-il en rajouter un deuxième en parallèle pour mettre à la place du END, sans le supprimer, comme END_WAIT. La structure de départ est faite, on attend un appui pour continuer. Que l'on mette END ou END_WAIT (comme exemple évidemment)... ça me fatigue de dire tout cela, et je vois bien au final que les gens s'en fou...

Une seule remarque, c'est dommage que dans ton manuel, les mots clés affichés ne soient pas des liens.

Bonne appétit, je vous en ai encore mis une bonne tartine!

Je viens de voir les deux messages, je ne vais tout de même pas tout effacer, donc Bon apéro et bon apétit!

Je viens juste de répondre à Severin (en allemand) pour lui donner dans sa langue, des conseils un peu plus précis pour la structuration de son programme. Lui aussi se bute sur la commande END dont il n'a pas compris le fonctionnement. J'ai corrigé une partie de son programme et lui laisse le soin d'en comprendre le sens et de l'appliquer au reste. Mais, pour que tout le monde en profite, voici, traduit en français, ma structuure de programme conseillée:

Début de traduction:
1. toutes les comandes LABEL
2. toutes les commandes DIM
( remarque: les points 1 et 2 peuvent être intervertis)
3. toutes les initialisations, code qui ne doit êtgre exécuté qu'au début du programme, construction de l'interface graphique (FORMs, BUTTONs, MENUs, ...)
4. la commande END !!!!!!!!!!!!!!!! Elle devrait se trouver exclusivement ici, une unique fois, dans un programme. A partir du début du programme et jusqu'à ce point, ce programme fonctionne dans un mode qui rappelle des versions anciennes de Basic, telles qu'elles existaient sous MS-DOS ainsi que sous d'autres anciens ordinateurs. La commande END bascule en mode Windows ! Ce mode est le grand Plus de Panoramic. A partir de ce moment, le programme entier sera piloté exclusivement par des évènements, comme c'est le cas de tous les autres programmes Windows. Qu'est-ce qu'un évènement ? Un clic sur un bouton, un menu ou un autre objet, la modification d'une cellule de données, l'écoulement d'un timer, la frappe d'une touche sur le clavier ainsi que beaucoup d'autres. En Panoramic, tous les évènements sont déclarés par des commandes ON_xxx, dont le paramètre est un numéro d'objet, suivi du nom d'une routine d'évènement. Cette routine sera appelée par Panoramic dès qu'un évènement arrive. Cet appel est effectué via une simulation d'une commande GOSUB. Une telle routine doit donc TOUJOURS se terminer par un RETURN, afin que Panoramic puisse continuer à gérer ses évènements.
5. toutes les routines évènements. Elles doivent commencer par un label qui a été déclaré par une commande LABEL en point 1 et qui a été signalée à Panoramic par une commande ON_xxx comme routine évènement. Elles doivent être terminées DYNAMIQUEMENT avec une commande RETURN. Aucune commande END n'a sa place ici (voir point 4)
6. toutes les routines internes. Mêmes remarques que pour point 5, moins bien sûr les comandes ON_xxx.

Remarque supplémentaire: une routine évènement peut appeler sans problème un sous-programme interne. Mais on devrait strictement veiller à ne JAMAIS appeler une routine évènement à partir d'une routine interne ou à partir d'une autre routine évènement. Ceci conduit en tous les cas à des problèmes de réentrance et se termine dans la plupart des cas par des crashs qui sont très difficiles à diagnostiquer.
Fin de traduction

J'ajoute que ceci est une structure générale, qui conduit à un programme valide en Panoramic, sans conflit. Il est bien évident qu'une fois qu'on a intégré le fonctionnement du mode évènement et l'esprit dans lequel Panoramic est rélisé, on peut déroger de ces règles si cela s'avère utile, mais on le fait alors en connaissance de cause. Mais je répète: la structure ci-dessus devrait être la structure de base de tout programme Panoramic. D'ailleurs, si l'on relit bien la rubrique "Conseils" de l'aide intégrée de Panoramic, on trouve exactement cela, tout comme d'ailleurs dans les exemples fournis avec Panoramic.

C'est à peu près ce que je donne, maintenant, comme structure à mes progs sauf
que sur les points 5 et 6 c'est plutôt :

_5(1) évènement (label:.....return)
_5(1)a sous évènement de 5(1) (label:...return)
_5(1a)1 ss sous évènement quand le point précédent est un form X (qui en fait ce conduit
comme un popup en html
_5(1)b
_5(1)c
_5(2)

_6 les fonctions réutilisables ou utilisées par plusieurs évènements / ss évènements

et c surtout pour mieux retrouver mes fonctions dans mon petit cerveau

Bonjour il est vrai que la commande END n'est pas très claire...

Voir l'excellente description faite par Klaus :
https://panoramic.1fr1.net/t1109-probleme-boucle-repeat-until-until-ignore

Là où je rejoins Cosmos c'est que les explications de Klaus et des autres seraient certainement mieux dans un tuto que dans un post qui fini par se perdre dans la masse... j'ai mis un petit moment pour retrouver le lien ci-dessus et c'est bien dommage.

@ Nardo

Oui, mais...
Je te laisse en reflexion sur le temps de travail pour récupérer tous les posts
les synthétiser et en faire un tuto qui doit pouvoir évoluer avec les avancés journalières
quand parfois nous sommes encore plus rapide....



Ps : j'ai jeté un oeil sur tes progs et ton truc pour le FTP m'intéresse, il faut que j'approfondisse
la nécessité pour mon prog et je reviendrai surement te casser les pieds sur le sujet.

Je suis bien d'accord : Bonjour le boulot !

Mais c'est ce que je fais actuellement lorsque je rencontre un problème : je parcours, fais des recherches sur l'ensemble du forum pour savoir si une solution existe...

Si quelque part on avait une FAQ cela simplifierai les choses et éviterai d'avoir toujours les même questions récurrentes...

PS: pour le FTP, ok pas de pb !!