Version instantanée du 30/12/2016 : PANORAMIC V 0.9.27i9

Essais concluants !
ça marche !

Merci Jack et bonne fin d'année 2016 !

Bonjour Jack !

Premiers tests avec un ancien programme en bas converti en exe.
Les 2 (bas et exe) fonctionnent correctement et le TERMINATE aussi.

Merci c'est super ! je vais pouvoir me pencher de nouveau sur GPP !!

Merci Jack,

Jack a écrit:

Téléchargez la, testez la, secouez la.

Ben.. on ne va pas se priver

Un premier compte-rendu:
TERMINATE et transformation en exécutable => OK

Essai sur la commande ON_MOUSE_DOWN N,Label

Code:

label pos
on_move 0,pos
alpha 1
end

pos:
caption 1,str$(mouse_x_position(0))
return

Ce code fonctionne, mais on est obligé de lâcher et de quitter le bandeau de FORM 0, pour que le sous-programme "pos:" fonctionne.
Est-il possible que cette commande agisse tant que le FORM bouge  

A+

PS: Je suis un âne, çà marche parfaitement. C'est mon code qui n'est pas bon.

Code:

label pos
ON_MOVE 0,pos
alpha 1
end

pos:
caption 1,str$(top(0))
return

Quelqu'un peut-il me dire pourquoi mon code n'affiche rien quand je clique sur le bouton

Code:

label pos,test

ON_USER_EVENT pos
alpha 1
button 2 : top 2,5 : left 2,WIDTH_CLIENT(0)-(WIDTH(2)+5) : caption 2,"Click"
on_click 2,test
end

pos:
print str$(USER_EVENT_LPARAM)
print str$(USER_EVENT_WPARAM)

return

test:
' print str$(USER_EVENT_LPARAM)
' print str$(USER_EVENT_WPARAM)
message "X"
return

Je suis curieux de voir à quoi peut servir ON_USER_EVENT L.

Autrement: J'ai tout testé, et tout fonctionne.  

A+

@Jean Claude

Ligne 2

Code:

ON_MOVE 0,pos

Qu’as-tu fais de ta mouse ?
Ne me dis pas que tu l’as passée au poêle !
Bon corrige comme ça

Code:

ON_MOUSE_MOVE 0,pos

Non il n'y a pas d'erreur Papydall,

Jack a écrit:

ON_MOVE N,Label : exécute le programme à partir du label L quand l'utilisateur bouge le FORM numéro N

Ce ne sont pas les mêmes commandes.
J'ai corrigé mon code, c'était le sous-programme pos: qui n'était pas adapté.


Pour ON_USER_EVENT, as-tu une solution ?

A+

Jean Claude a écrit:

Je suis curieux de voir à quoi peut servir ON_USER_EVENT L.

Ça c’est un truc pour les grands (genre Klaus et semblables), pas pour Papydall !
Donne-toi la peine de cliquer sur ce lien et tu en sauras davantage.

Heu... ben... oui, là je ne touche pas. Comme tu dis "c'est pour les grands".
Mais, un jour, je serais grand...

On grandira ensemble.

J'ai quand même un problème que je ne m'explique pas avec cette version, en utilisant les nouvelles fonctions.
Un petit exemple vite fait (incomplet): sub de dessin d'un rectangle à la souris clic au départ, glissement, et relâchement à l'arrivée:

Code:

PICTURE 1: FULL_SPACE 1
Desic(1)
END
' =====
SUB Desic(p%)
  LABEL Clic,Clim,Fclic
  DIM_LOCAL ff%,x1%,y1%,x%,y%
  2D_TARGET_IS p%
  ON_MOUSE_DOWN p%,Clic
  WHILE ff% = 0: PAUSE 200: END_WHILE: EXIT_SUB
Clic:
  x1% = MOUSE_X_POSITION(p%): y1% = MOUSE_Y_POSITION(p%)
  2D_PEN_DOT: 2D_FILL_OFF: CLIPBOARD_COPY p%
  ON_MOUSE_MOVE p%,Clim: ON_MOUSE_UP p%,Fclic
RETURN
Clim:
  x% = MOUSE_X_POSITION(p%): y% = MOUSE_Y_POSITION(p%)
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN
Fclic:
  OFF_MOUSE_MOVE p%
  2D_PEN_SOLID
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN
END_SUB

Dès que je clique dans le picture (donc je déclenche le ON_MOUSE_DOWN), je pars en erreur sur la première directive du programme:
- Ici il me dit que le Picture est déjà défini (OBJECT already defined Line:1)
- Si c'est un Label, il me dit qu'il est déjà défini (LABEL defined twice Line:1)
comme si on reéxécutait le programme depuis le début...

Voici comment je fais et ça marche.

Code:

LABEL Clic,Clim,Fclic
DIM ff%,x1%,y1%,x%,y% ,p%
p% = 1 : PICTURE p%: FULL_SPACE p% : 2D_TARGET_IS p%
ON_MOUSE_DOWN p%,Clic

END
' =====

Clic:
  x1% = MOUSE_X_POSITION(p%): y1% = MOUSE_Y_POSITION(p%)
  2D_PEN_DOT: 2D_FILL_OFF: CLIPBOARD_COPY p%
  ON_MOUSE_MOVE p%,Clim: ON_MOUSE_UP p%,Fclic
RETURN
Clim:
  x% = MOUSE_X_POSITION(p%): y% = MOUSE_Y_POSITION(p%)
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN
Fclic:
  OFF_MOUSE_MOVE p%
  2D_PEN_SOLID
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN

Personnellement j’évite d’insérer des s/p (label) dans une sub ; je les mets en dehors de la sub.

Je sais bien papydall que ça marche en dehors d'une sub, mais je voulais en profiter dans ma sub de dessin, pour éviter ces satanés Timers qui me posent des problèmes, alors ce ON_MOUSE_DOWN est la solution idéale.
Et je voudrais bien savoir pourquoi ça ne marche pas dans une sub, du moins celle-ci.

Quant à ne pas mettre de s/p dans une sub, tu es bien obligé si tu as des événements à traiter, si tu les mets en-dehors ce n'est plus une sub mais un bout du programme, indissociable de celui-ci (avec les s/p qui se baladent ailleurs).
Pour moi une sub est une entité à part, insérable telle quelle dans n'importe quel programme, il suffit de respecter les paramètres d'entrée et de sortie, le reste est écrit une fois pour toutes, c'est une 'boîte noire'. C'est dans cet esprit que j'utilise ma bibliothèque de subs (près de 400 éléments quand même)

Juste une petite remarque pour t'embêter:

Citation :

je l’ai mets en dehors de la sub

oh !

Ok ! Je les mets en dehors de la sub.

Bonjour tout le monde!

@JL35
Ton code ne peut pas marcher car dans ta sub tu définis des variable locales, et dès que 'exit_sub' est atteind, ces variables sont détruites; donc 'x%,y%,...' ne sont plus reconnus. De plus 'ff%' valant toujours 0, tu te retrouve avec une boucle infini + events ---> ça ne fait pas bon ménage ça!
Essaye plutôt comme ça:

Code:

DIM ff%,x1%,y1%,x%,y%,p% : p%=1
PICTURE 1: FULL_SPACE 1
Desic(1)
END
' =====
SUB Desic(p%)
  LABEL Clic,Clim,Fclic
  2D_TARGET_IS p%
  ON_MOUSE_DOWN p%,Clic
'  WHILE ff% = 0: PAUSE 200: END_WHILE
  EXIT_SUB
Clic:
  x1% = MOUSE_X_POSITION(p%): y1% = MOUSE_Y_POSITION(p%)
  2D_PEN_DOT: 2D_FILL_OFF: CLIPBOARD_COPY p%
  ON_MOUSE_MOVE p%,Clim: ON_MOUSE_UP p%,Fclic
RETURN
Clim:
  x% = MOUSE_X_POSITION(p%): y% = MOUSE_Y_POSITION(p%)
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN
Fclic:
  OFF_MOUSE_MOVE p%
  2D_PEN_SOLID
  CLIPBOARD_PASTE p%: 2D_RECTANGLE x1%,y1%,x%,y%
RETURN
END_SUB

Bon réveillon à tous!

Bonjour silverman,

Je ne suis pas du tout d'accord avec toi !
Les variables x% et y% sont bien des variables locales qui ne sont utilisées que dans la sub et donc n'ont pas à être reconnues ailleurs ! Dans mon exemple aucune variable globale n'est déclarée ni utilisée (tu as confondu mon code avec celui de papydall ?).

Et exit_sub n'est jamais atteint, because plantage préalable.
Comme je l'ai dit, l'exemple que j'ai donné est très incomplet, la variable ff% est destinée à être utilisée pour sortir de la sub, mais n'est pas (encore) exploitée dans l'exemple, puisque on ne va pas si loin... je voulais simplement montrer que ça plantait au 1er clic souris, c'est tout, donc inutile d'aller plus loin et de donner un exemple complet de 1000 lignes.

Le code existe complet et fonctionne très bien, mais avec surveillance de la souris avec un timer, ce que je comptais éviter avec ces nouvelles instructions.

@JL35,

Ton bout de code me laisse perplexe.
Je l' ai pris et aéré ce qui donne ceci :

Code:

PICTURE 1
FULL_SPACE 1
Desic(1)
END
' =====
SUB Desic(p%)
  LABEL Clic,Clim,Fclic
  DIM_LOCAL ff%,x1%,y1%,x%,y%

  2D_TARGET_IS p%
  ON_MOUSE_DOWN p%,Clic

  WHILE ff% = 0
  PAUSE 200
  END_WHILE
  EXIT_SUB

  Clic:
      x1% = MOUSE_X_POSITION(p%)
      y1% = MOUSE_Y_POSITION(p%)
      2D_PEN_DOT
      2D_FILL_OFF
      CLIPBOARD_COPY p%
      ON_MOUSE_MOVE p%,Clim
      ON_MOUSE_UP p%,Fclic
      RETURN

  Clim:
      x% = MOUSE_X_POSITION(p%)
      y% = MOUSE_Y_POSITION(p%)
      CLIPBOARD_PASTE p%
      2D_RECTANGLE x1%,y1%,x%,y%
      RETURN

  Fclic:
      OFF_MOUSE_MOVE p%
      2D_PEN_SOLID
      CLIPBOARD_PASTE p%
      2D_RECTANGLE x1%,y1%,x%,y%
      RETURN
END_SUB

Même si on sortait de la boucle, on ne déclarerait pas les labels, enfin leurs fonctions.
il y a un beau EXIT_SUB juste avant.

et, si je fais sauter les 4 lignes (while...exit_sub)
J' ai un message "RETURN with out GOSUB"

J' ai fait sauter les RETURN
et là j' ai bien peur que Silverman ait raison pour x1% et les autres...
si la déclaration des fonction est faite, les variables elles n' existent plus.

@silverman
Je vais regarder de plus près, mais c'est une disposition que j'utilise couramment dans les subs (avec la version précédente de l'éditeur), il me semble que la déclaration des Labels est analysée par l'éditeur avant l'exécution, donc la boucle while...end_while n'est pas en cause, mais bon je vais essayer une autre disposition.
On doit pouvoir écrire les ON_MOUSE... ,Label n'importe où dans le code il me semble, ou alors ça perd beaucoup de son intérêt s'il faut le faire avant exécution.

@ygeronimi
Si tu fais sauter les Return ça ne veut plus rien dire, et je ne vois pas le rapport avec les variables, je ne vois pas pourquoi elles n'existeraient plus tant qu'on est dans la sub.

Et je ne vois toujours pas pourquoi cette erreur sur la ligne 1, double déclaration ?

Papydall a écrit:

Personnellement j’évite d’insérer des s/p (label) dans une sub ; je les mets en dehors de la sub.

Perso, je suis du même avis. Mais pour moi c'est simplement pour éviter des embrouilles...

Bon, y faut que je retourne à la fête...

J'ai essayé plusieurs configurations, et j'en déduis que jusqu'à preuve du contraire, les instructions ON_MOUSE ne marchent pas à l'intérieur d'une Sub, donc j'abandonne cette façon de faire.

Et, quand même, bonne année à tous !

Bonne et heureuse année à tous !

Mon but n’est pas de faire de polémique sur la façon de coder.
Je donne ici simplement mon avis qui n’engage que moi.

Voici comment je vois les choses en ce qui concerne les sous-programmes.
Je distingue les sous-programmes événementiels et les sous-programmes non événementiels.

1) Les s/p événementiels sont exécutés quand un événement donné a lieu. Par exemple un clic sur un bouton déclenche un événement.
Le gestionnaire des événements ira chercher le s/p associé,  l’exécute puis rend la main au programme principal.
En Panoramic ce type de s/p est défini par un label, lequel se termine par RETURN.
Il peut arriver qu’un tel s/p ne soit jamais exécuté, faute de présence de l’événement déclencheur.

2) Les s/p non événementiels peuvent être définis soit par un label  et un return (comme les s/p événementiels) soit par SUB / END_SUB.
Cette dernière façon de concevoir un s/p est préférable car elle permet le passage des paramètres au s/p et aussi et surtout de pouvoir déclarer et utiliser des variables locales.
L’exécution de ce type de s/p se fait uniquement par un appel (l’identificateur de la SUB avec les éventuels paramètres)  du programme principal ou d’un autre s/p.

Panoramic ne permet pas les s/p du type SUB / END_SUB  imbriqués. Il nous faut donc les déclarer séparément.
De mon point de vue, j’évite de coder des s/p (label / return) dans les s/p (SUB / END_SUB).
Dernier point de mon point de vue : un s/p (SUB / END_SUB)  doit être court (une page écran par exemple, pas plus quitte à le subdiviser en deux s/p ou plus), lisible, facilement modifiable, ne contenant ni GOTO, ni GOSUB, ni définition de s/p événementiels.

Je pense (mais je peux me tromper) qu’un s/p événementiel, une fois exécuté rend la main au programme PRINCIPAL et non au s/p dans lequel il a été  déclaré.

Jack peut nous donner plus de précisions sur ce point.

Sur ce, je vous souhaite une bonne et heureuse année et beaucoup de codes en Panoramic avec des sous-programmes événementiels et non événementiels.

Pour ce que j' ai pu voir :

Sub MaSub1(par%,par$)
   MaSub2(par%,....)
End_Sub

c' est possible

Sub MaSub1()
   label:
   return
End_Sub

cà ca bug

Sub MaSub1()
label:
End_Sub

c' est possible sous certaine condition (goto)

Label:
   MaSub1()
return

c' est possible

JL35 a écrit:

Les variables x% et y% sont bien des variables locales qui ne sont utilisées que dans la sub et donc n'ont pas à être reconnues ailleurs !

Ces variables, tu les as déclarées dans une sub, mais elles doivent être en permanence reconnus dans les EVENTS que tu as inclus dans la sub! Or, quand un 'end_sub' ou 'exit_sub' est atteind, les variables locales de ta sub sont détruites, mais pas l'event, il peut toujours être déclenché lui!
Ce n'est pas parceque tu déclenches un event contenu dans une sub que les variables locales contenu dans l'event vont être recréés! il faut re-appeler la sub pour recréer les variables locales!
Et bloquer la sortie d'une sub avec une boucle infini comme tu l'as fait est inutile, car l'appel d'un event va 'casser' la boucle et provoquer un plantage(exactement comme avec les timers) vu que panoramic n'est pas conçu pour ce cas de figure.

Un event doit être perçu comme un gosub conditionnel. Tu peux centraliser les events dans une sub, ce n'est pas un problême du moment que tu n'utilises que des variables globales.

Je ne suis pas d'accord avec vos arguments, parce que j'ai des subs qui fonctionnent parfaitement et sans problèmes avec les principes que vous déclarez impossibles, le seul problème que j'ai eu c'est avec les nouveaux MOUSE_..., mais bon, j'abandonne ça du moins pour les subs.
Sinon, dans une sub je fais appel à des sous-programmes, ou à des traitements d'événements (ON_CLICK par exemple), sans problèmes, il faut seulement faire attention à bien tout supprimer avant l'exit_sub ce qui a été créé dans la sub.

Je ne vais pas polluer plus longtemps ce sujet, et je vais en rester là.