Version instantanée du 12 septembre 2012 PANORAMIC V0.9.24i2

Invité

Je suis désolé, Nardo
Je venais faire cet essai, en me connectant, je lis le rapport que vous faisiez et je me suis dis que cela pouvait être intéressant à regarder. Mais je n'ai pas lu ton post car je devais partir, et cela me semblais trop long à analyser en pensant regarder ce soir. Sinon je me serais abstenu.

Simple question comme cela?:
Est-ce SUB et Funct pourrai pas être la même chose. Il suffit de faire return x... avant END_SUB. Non?

EDIT
Vous en dites des choses en si quelques heures

Sujet: re Jeu 13 Sep 2012 - 20:31

Ben à force de papoter, j'ai rien codé depuis 3 jours ! Laughing

Edit : Pour un menu avec main_menu, puis faire autrement avec sub :

Code:: Label Menu

Init_F0()
end

sub Init_F0()
Dim_local x%
width 0,500:height 0,350:top 0,(screen_y-350)/2:left 0,(screen_x-500)/2
caption 0,"Viewer 3DS":font_name 0,"Times new roman":font_size 0,10
main_menu 1
for x%=2 to 10:sub_menu x% :parent x%,1:on_click x%,menu :next x%
end_sub

menu:
dim_local M%,x%
for x% = 2 to 10
if clicked(x%)=1 then M%=x%
next x%
select M%
case 2
case 3
case 4
case 5
case 6
case 7
case 8
case 9
case 10
end_select
return

cosmos70 a écrit:: Simple question comme cela?:
Est-ce SUB et Funct pourrai pas être la même chose. Il suffit de faire return x... avant END_SUB. Non?

La structure d’une fonction ressemble beaucoup à celle d’une procédure.
La déclaration d’une fonction commence par un mot réservé.

En attendant que Jack nous délivre la prochaine version pour voir quel mot réservé a-t-il choisi, je vais supposer que c’est FUNCTION.
Tout autre mot n’a aucune incidence sur ce qui suit.

Donc, on déclare une fonction, par exemple ainsi :

Code:: FUNCTION NomFonction(<liste des paramètres>)
....
....
NomFonction = resultat
END_FUNCTION

La transmission des paramètres se réalise pour les fonctions strictement de la même manière que pour les procédures.
Une fonction doit OBLIGATOIREMENT retourner à l’appelant un résultat.
Il faut donc qu’il existe (au sein de la fonction et avant END_FUNCTION) une instruction d’affectation du résultat à NomFonction.
Comme NomFonction est maintenant un identificateur ayant une valeur, on peut le mettre dans une expression et c’est là la différence fondamentale avec une procédure.

Exemple :
Supposons que l’on veuille enrichir la panoplie des fonctions mathématiques de PANORAMIC.
Panoramic possède entre autres les fonctions SIN(x), COS(x), etc..Mais les fonctions SEC(x) et COSEC(x) lui fond defaut.
Qu’à cela ne tienne, on va les définir :
En effet SEC(x) (lire sécante de x) et COSEC(x) (lire cosécante de x) sont définies mathématiquement ainsi :
SEC(x) = 1/COS(x)
COSEC(x) = 1/SIN(x)

Code:: FUNCTION sec(x)
sec = 1/cos(x)
END_FUNCTION

FUNCTION cosec(x)
Cosec = 1/sin(x)
END_FUNCTION

Après avoir définit ces 2 fonctions, on peut les utiliser comme ceci :

Code:: ....
a = pi/4
print "SEC(" ;str$(a) ; ") = " ;sec(a)
print "COSEC(" ;str$(a) ; ") = " ;cosec(a)

On peut également les utiliser dans des expressions

Code:: .....
y =sec(0.5) + 4 * cosec(3)

Remarque : les arguments de sec et cosec sont, comme ceux de sin et cos en radians.

Une fonction ne retourne pas seulement une valeur numérique.
Elle peut retourner aussi bien un caractère qu’une chaîne des caractères etc.

sunny

Cette syntaxe est ambigüe :

Code:: FUNCTION sec(x)
sec(x) = 1/cos(x)
END_FUNCTION

Affectation d'un tableau ?...

pourquoi pas un mot spécifique, dans le style GFA

Code:: FUNCTION sec(x)
RETURN 1/cos(x)
END_FUNCTION

ou alors en utilisant le nom de la fonction :

Code:: FUNCTION sec(x)
sec= 1/cos(x)
END_FUNCTION

reste à savoir ce qu'a prévu Jack... (à mon avis la 2eme solution, cf Delphi)

En principe, c'est plutôt cette syntaxe:

Code:: FUNCTION sec(x)
sec= 1/cos(x)
END_FUNCTION

Le RETURN est un peu ambigu par rapport au sous programme, je trouve

Invité

Ok merci.
Bon rebelote, j'ai appuyé sur déconnexion à la place d'envoyer.

Il me semblait que certain langage employait return = ou result. Mais l'explication est très clair. On reçoit le résultat de ce qu'on envoie.

En AutoIt c'est Func, c'est pour cela que j'ai employé ce mot à la place de fonction.

@Nardo26 et Jicehel

Vous avez raison : le retour de la fonction se fait avec le nom de la fonction SANS le paramètre
(c'est corrigé)

Code:: SEC = 1/COS(X)

C’est d’ailleurs la syntaxe du PASCAL

Je m’emballe un chouia : je suis content de cette petite (r)évolution de PANORAMIC,
et je ne fait plus attention à certaines choses.

L’autre disait : " Rien ne sert de penser, il faut réfléchir avant "
A méditer!

@Papydall:
Tu parles très bien des fonctions. En tout cas des fonctions qui retournent des valeurs numériques.

mais il faut aussi que tu inclues dans ton raisonnement des fonctions qui retournent une chaîne de caractères, à l'image des fonctions Panoramic comme TEXT$() etc.

On devrait pouvoir définit ainsi une fonction "string" de la manière suivante:

Code:: dim r$, s$, t$
s$ = "Ceci est un"
t$ = "exemple"
r$ = concat$(s$,t$)
' ici, r$ contient "Ceci est un exemple"

FUNCTION concat$(x$,y$)
concat$ = x$ + " " + y$
END_FUNCTION

Oui Klaus, tu as raison et pour bien faire il faut également prévoir % .... Wink

Eventuellement. Cependant, les fonctions et variables Panoramic qui retounent un résultat numérique sous forme de valeur entière, ne sont jamais affecté d'un %. Pourquoi ? Il faudra le demander à Jack. Pense à des fonctions comme INT(), TOP() etc et des variables systèmes comme NUMBER_CLICK etc.

Pour rester cohérent avec le schéma de nommage de Panoramic, il suffira de $ pour désigner une fonction qui retourne une chaîne de caractères. Et sans le $, c'est implicitement une valeur numérique, quelle qu'elle soit.

@Klaus

Tu as parfaitement raison de dire qu’une fonction peut retourner une chaine de caractères.
Je l’ai déjà signalé, mais je n’ai pas donné d’exemple

papydall a écrit:: Une fonction ne retourne pas seulement une valeur numérique.
Elle peut retourner aussi bien un caractère qu’une chaîne des caractères etc.

PS:
Une fonction peut et doit retourner un résultat de n’importe quel type de données compris par le langage de programmation, a savoir une valeur numérique entière , réelle, boolienne , tableau , caractère, chaine de caractères, et plus si affinité : type pointeur, intervalle, énuméré, enregistrement ,etc.
Bref, tout type de données que le langage permet de définir.

Salut tout le monde.

Je m’amuse avec les procédures SUB .... END_SUB
Le code suivant détermine si une chaine de caractères (simple mot ou une phrase ou un texte) est un PALINDROME.
Un palindrome est un mot ou un texte qu’on peut lire aussi bien de gauche à droite que de droite à gauche (abstraction faite des espaces, des apostrophes et d’autres signes (diacritiques, trémas, etc.))
J’utilise des procédures qui en appellent d’autres procédures :
Une procédure SPACE_OFF() qui élimine les espaces et autres apostrophes.
Une procédure INVERSE_CHAINE() qui ..... inverse la chaine !
Une procédure PALINDROME() qui teste si la phrase est un palindrome.

Le retour des résultats des ces procédures vers l’appelant se fait au travers des variables globales.
Ce genre de programmation n’est pas optimal ; il n’est pas clair non plus.

Il aurait été plus simple de le coder avec les fonctions.
En attendant l’implémentation de ces dernières, voici le mauvais code, mais le but ultime de la programmation n’est-il pas de trouver des solutions à des problèmes ?

Code:: ' ******************************************
' * palindrome.bas *
' ******************************************

' ******************************************************************************
' * Un palindrome désigne un texte ou un mot dont l'ordre des lettres reste le *
' * même qu'on le lise de gauche à droite ou de droite à gauche, comme dans *
' * l'expression "Esope reste ici et se repose" *
' ******************************************************************************

' Module directeur
dim s$,t$,a$,ok%,p$ : ' Variables globales
demarrer() : ' Procédure principale qui appelle les autres
end
' Fin du module directeur
' ******************************************************************************
SUB demarrer()
init()
go()
END_SUB
' ******************************************************************************
' initialisation
SUB init()
color 0,0,0,0 : font_color 0,0,255,0: font_size 0,12 : font_bold 0
' s$ = "SALUT LES PANORAMICIENS "
' s$ = "ELU PAR CETTE CRAPULE"
' s$ = "KARINE ALLA EN IRAK"
s$ = "ENGAGE LE JEU QUE JE LE GAGNE"
' s$ = " TA BELLE PORTE S'USE TROP ELLE BAT"

' ******************* Et pour faire plaisir à Klaus
' Remarque : j'ai enlevé les trémas sur les U
' s$ = "EINE GULDNE GUTE TUGEND LUGE NIE" : ' "Une bonne vertu en or ne mens jamais"
t$ = ""
END_SUB
' ******************************************************************************
SUB go()
palindrome(s$)
print_locate 50,50 : print s$ : print_locate 50,80
if ok% = 1
print " est un palindrome"
else
print " n'est pas un palindrome"
end_if
END_SUB
' ******************************************************************************
' élimine tous les espaces et les apostrophes d'un texte
SUB space_off(chaine$,result$)
DIM_LOCAL L%,I%,C$,space$,apostrophe$
L% = len(chaine$) : T$ = "": space$ = chr$(32) : apostrophe$ = "'"
for i% = 1 to l%
c$ = mid$(chaine$,i%,1)
if (c$ <> space$) and (c$ <> apostrophe$) then t$ = t$ + c$
next i%
END_SUB
' ******************************************************************************
' Inverse un texte
SUB inverse_chaine(chaine$,result$)
DIM_LOCAL l%,i%
space_off(chaine$,t$)
l% = len(t$) : a$ = ""
for i% = l% to 1 step -1
a$ = a$ + mid$(t$,i%,1)
next i%

END_SUB
' ******************************************************************************
' Teste si le texte est un palindrome
SUB palindrome(phrase$)
space_off(phrase$,t$)
inverse_chaine(t$,a$)
if t$ = a$ then ok% = 1 : else : ok% = 0
END_SUB
' ******************************************************************************

!!! VIVE LES SUBs !!!

Intéressant les palindromes,

Quant au code, YA MÊME PLUS DE LABEL....

Bravo

A+

J'aimerais faire des sources aussi joli.
Efficace et belle présentation Wink

Avec les fonctions ça sera beaucoup mieux !
Et avec la transmission des paramètres par référence ça sera plus … efficace !
Et avec la récursivité ça sera....plus .....concis, plus ..... élégant, je ne vous dit pas plus.
Vous êtes assez compétant pour savoir mieux que moi.

lol!

@Jean Claude
Les LABELs on n'en a presque plus besoin!

Voici un code à l’ancienne avec LABEL et GOSUB /RETURN

Code:: ' Codage à l'ancienne avec LABEL et GOSUB ... RETURN
label init, L1,L2,L3,L4,L5,quitter
gosub init
end

init:
button 1 : top 1,50 : left 1,50 : caption 1,"OK" : on_click 1,L1
button 2 : top 2,50 : left 2,150 : caption 2,"OK" : on_click 2,L2
button 3 : top 3,50 : left 3,250 : caption 3,"OK" : on_click 3,L3
button 4 : top 4,50 : left 4,350 : caption 4,"OK" : on_click 4,L4
button 5 : top 5,50 : left 5,450 : caption 5,"OK" : on_click 5,L5
button 6 : top 6, 100 : left 6,250 : caption 6,"QUITTER" : on_click 6,quitter

return

L1:
message "Hello, je suis en L1"
return

L2:
message "Hello, je suis en L2"
return

L3:
message "Hello, je suis en L3"
return

L4:
message "Hello, je suis en L4"
return

L5:
message "Hello, je suis en L5"
return

quitter:
terminate
return

Voici un nouveau code avec SUB, plus de GOSUB/RETURN
Si les ON_CLICK, ON_CHANGE, ON_... pouvaient appeler les procédures SUB,
on n'aura plus besoin ni de LABEL, ni de GOSUB.
On pourrait à la rigueur utiliser LABEL pour faire un GOTO, ce qui est anti programmation structurée !

Code:: ' Nouveau codage avec SUB : plus de GOSUB ... RETURN, un seul LABEL
' Si les ON_CLICK, ON_CHANGE, ON_... pouvaient appeler les procédures SUB,
' on n'aura plus besoin ni de LABEL , ni de GOSUB
label clic
init()
end

clic:
if clicked (1) = 1 then L1() : return
if clicked (2) = 1 then L2() : return
if clicked (3) = 1 then L3() : return
if clicked (4) = 1 then L4() : return
if clicked (5) = 1 then L5() : return
if clicked (6) = 1 then quitter() : return

SUB init()
DIM_LOCAL I%
FOR I% = 1 to 5
BUTTON I% : TOP I%,50 : LEFT I%,100*I%-50 : CAPTION I%,"OK"
NEXT I%
button 6 : top 6, 100 : left 6,250 : caption 6,"QUITTER"
FOR I% = 1 to 6 : ON_CLICK I%,clic : next I%

END_SUB

SUB L1()
message "Hello, je suis en L1"
END_SUB

SUB L2()
message "Hello, je suis en L2"
END_SUB

SUB L3()
message "Hello, je suis en L3"
END_SUB

SUB L4()
message "Hello, je suis en L4"
END_SUB

SUB L5()
message "Hello, je suis en L5"
END_SUB

SUB quitter()
terminate
END_SUB

@ Papydall
C'est génial ton illustration à propos de SUB. Justement, je me contente pour le moment d'utiliser SUB à la place des GOSUB's pour essayer après de comprendre petit à petit les procédures avec paramètres. J'ai testé ton dernier exemple avec une petite modification car je crois qu'un seul RETURN dans le label clic: suffira.

Code:: ' Nouveau codage avec SUB : plus de GOSUB ... RETURN, un seul LABEL
' Si les ON_CLICK, ON_CHANGE, ON_... pouvaient appeler les procédures SUB,
' on n'aura plus besoin ni de LABEL , ni de GOSUB
label clic
init()
end

clic:
if clicked (1) = 1 then L1() : ' return
if clicked (2) = 1 then L2() : ' return
if clicked (3) = 1 then L3() : ' return
if clicked (4) = 1 then L4() : ' return
if clicked (5) = 1 then L5() : ' return
if clicked (6) = 1 then quitter()
return

SUB init()
DIM_LOCAL I%
FOR I% = 1 to 5
BUTTON I% : TOP I%,50 : LEFT I%,100*I%-50 : CAPTION I%,"OK"
NEXT I%
button 6 : top 6, 100 : left 6,250 : caption 6,"QUITTER"
FOR I% = 1 to 6 : ON_CLICK I%,clic : next I%
END_SUB

SUB L1()
message "Hello, je suis en L1"
END_SUB

SUB L2()
message "Hello, je suis en L2"
END_SUB

SUB L3()
message "Hello, je suis en L3"
END_SUB

SUB L4()
message "Hello, je suis en L4"
END_SUB

SUB L5()
message "Hello, je suis en L5"
END_SUB

SUB quitter()
terminate
END_SUB

Le SUB est génial car son existence allège beaucoup le programme avec les labels et les variables.
ENCORE BRAVO ET MERCI JACK pour le cadeau. cheers

A+

Salut Topmozika

Tu as raison, un seul RETURN suffit.
Si j’en ai mis plusieurs, c’est pour sortir VITE du sous-programme sans tester les conditions suivantes qui deviennent nécessairement fausses.
On aurait pu imbriquer des IF…ELSE…END_IF (je ne suis pas ami avec cette structure).
Au final, chacun a ses préférences !

A+

J’essaye de vêtir mes anciens programmes des costumes neufs farao

Je veux dire les recoder en utilisant les toutes fraiches SUB … END_SUB. Like a Star @ heaven

L’absence de l’instruction EXIT_SUB se fait sentir et pour de bon! Sad

Pour la contourner : je déclare un LABEL Exit, je le mets juste avant END_SUB et à l’intérieur de SUB, je fais GOTO Exit.

Code:: ....
LABEL Exit_Truc, Exit_Machin
....
SUB Truc()
....
IF .... goto Exit_Truc
....
Exit_Truc :
END_SUB

SUB Machin()
....
IF .... goto Exit_Machin
....
Exit_Machin :
END_SUB

Ça marche mais ce n’est plus de la PROGRAMMATION STRUCTUREE ! albino

, c’est plutôt de la « PROGRAMMATION SAUVAGE » elephant

!

Et que dire, si on a plusieurs SUB qu’on veut EXITer ? (et non exciter hein!) Wink

Nombre de messages : 7112 Localisation : 77 Date d'inscription : 29/11/2007

comme ces labels ne sont utilisés qu'en local dans la sub, ce serait mieux de les déclarer à l'intérieur de la sub elle-même:

Code:: SUB Truc()
IF LABEL("Exit_Truc") = 0 THEN LABEL Exit_Truc

@Jl35
Pardon !
Mais je pense que ce que tu dis est une erreur d’analyse.
Une procédure n’est pas faite pour être appelée une SEULE fois.
Si tu mets les LABEL à l’intérieur de la procédure, le 1er appel s’exécute bien mais lors du 2ème c’est l’erreur garantie :Label defined twice

lol!

Sauf si LABEL_LOCAL comme l'a suggéré Klaus....

A+

Mais il serait plus judicieux de créer EXIT_SUB, c’est plus simple non ?

Dernière édition par JL35 le Sam 15 Sep 2012 - 21:27, édité 1 fois

Ben non mon ami papydall, regarde la 1ère ligne du sub, si le label existe déjà (2ème appel et suivants) il n'est pas redéclaré !

Je répète:
SUB Truc()
IF LABEL("Exit_Truc") = 0 THEN LABEL Exit_Truc

ou évidemment LABEL_LOCAL ~~c'est~~ serait encore mieux.

Ben là Papydall, je ne suis pas d'accord puisque JL35 mets un test pour vérifier si le bael a déjà était déclaré, mais en effet il y a un risque. Si l'on utilise un nom usuel genre quitter. Si ce label est définit dans une autre procédure, le programme considérera l'étiquette déjà définit mais ira se brancher sur la mauvaise étiquette quand on fera le saut vers l'étiquette.
D'où en effet l’intérêt des LABEL_LOCAL pour cet usage. Sinon ne pas utiliser ce type de saut mais préférer des appel à d'autre sous programme (si qui peut être fait pour presque tout en dehors de la gestion des événements si je ne m'abuse.

» Version instantanée du 8 septembre 2012 PANORAMIC V 0.9.24i1
» Version instantanée du 16 mai 2012: PANORAMIC V 0.9.23i6
» Version instantanée du 25 octobre 2012: PANORAMIC V 0.9.24i5
» Version instantanée du 28 janvier 2012: PANORAMIC V 0.9.23i4
» Version instantanée du 13 février 2012: PANORAMIC V 0.9.23i5