Utilisation d'Élip

Je me suis mis à utiliser Élip, pour voir,
et je viens d'observer des choses curieuses.
Par exemple :

Code:

move:
   if (mouse_x_position(500)-PIX%)>0 and (mouse_x_position(500)-PIX%)<1200
      if mouse_y_position(500)-PIY%>0 and (mouse_y_position(500)-PIY%)<454
         sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
   end_if
return

Il se produit alors l'erreur suivante :

(la ligne dite 64, c'est la 2° ligne de ce qui précède (celle qui finit par 1200)
Si je la transforme en :
if (mouse_x_position(500)-PIX%)>0 and (mouse_x_position(500))<1200
L'erreur se produit alors à la ligne suivante, pour la même raison.
Et si je fais :

Code:

move:
   V1M%=mouse_x_position(500)-PIX%
   V2M%=mouse_y_position(500)-PIY%
   if V1M%>0 and V1M%<1200
      if V2M%>0 and V2M%<454
         sprite_position 510,V1M%,V2M%
      end_if
   end_if
return

Là, plus d'erreur.


Autre exemple :
Si je fais :

Code:

V1M%=int(mouse_x_position(200)/41)+1
V2M%=int(mouse_y_position(200)/41)+1
caption 0,str$(V1M%)+"-"+str$(V2M%)

Cela me donne des résultats assez abracadabrants.
Et si je fais :

Code:

V1M%=mouse_x_position(200) : V1M%=int(V1M%/41)+1
V2M%=mouse_y_position(200) : V2M%=int(V2M%/41)+1
caption 0,str$(V1M%)+"-"+str$(V2M%)

Là, ça marche impecc.

Bonjour JJN4 et bonjour à tous !

@JJN4
Bloque dès le début du sous-programme MOVE: l’évènement qui le déclenche (un "ON_???? 500,move"  je suppose ?) par l’instruction OFF_????…
Puis, à la fin du sous-programme, avant le RETURN, réactive-le par ON_????…

Code:

move:

  OFF_???? :' ajouté par Marc

  if (mouse_x_position(500)-PIX%)>0 and (mouse_x_position(500)-PIX%)<1200
      if mouse_y_position(500)-PIY%>0 and (mouse_y_position(500)-PIY%)<454
        sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
  end_if

  ON_????,move :' ajouté par Marc

return

C’est peut-être l’origine des dysfonctionnements que tu rencontres.

Bonne continuation !

Deux remarques:

1.

Code:

  if (mouse_x_position(500)-PIX%)>0 and (mouse_x_position(500)-PIX%)<1200
      if mouse_y_position(500)-PIY%>0 and (mouse_y_position(500)-PIY%)<454
        sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
  end_if

je le coderais plutôt comme ceci:

Code:

  if ((mouse_x_position(500)-PIX%)>0) and ((mouse_x_position(500)-PIX%)<1200)
      if ((mouse_y_position(500)-PIY%)>0) and ((mouse_y_position(500)-PIY%)<454)
        sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
  end_if

2. Marc a raison avec son ajout. En effet, si tu bouges la souris, les coordonnées retournées par mouse_?_position changent en temps réel. Il peut arriver que leurs valeurs change PENDANT l'exécution de ta structure des IFs imbriqués, et le résultat sera aberrant.

Pire: ces évènements (mouse_move etc) arrivent en rafale tant que la souris bouge. Et l'appel d'une routine évènement n'est pas bloquant. Autrement dit, une routine évènement peut être interrompue à tout moment, MEME EN PLEIN MILIEU D'UNE COMMANDE PANORAMIC, par l'arrivée d'un autre évènement, du même type (ou d'un autre, d'ailleurs). Mais s'il s'agit d'un évènement du même type, l'exécution en cours de la routine évènement sera interrompue et lancée à nouveau à partir de son début, changeant du même fait la valeur de toutes les variables impliquées dans le calcul.

Information importante: les routines évènement en Panoramic NE SONT PAS REENTRANTRANTES !

Il faut donc absolument les protéger contre un nouvel appel alors que l'appel courant n'est pas entièrement traité.

Et c'est exactement ce que l'ajout de Marc fait.

Cette réflexion est d'ailleurs valable pour absolument toutes les routines évènnement. Maintenant, il y a des types d'évènement pour lequel le risque est peu important (ON_TIMER par exemple, ou ON_CLOSE). Mais le risque est grand pour tous les évènement pouvant se produire en série, ce qui est le cas de ON_MOUSE_MOVE par exemple, ou d'ailleurs un ON_TIMER avec une intervalle très courte. De façon générale, tout évènement entraînant un traitement complexe ou long doit absolument être protégé de cette manière.

La bonne manière de coder de tels routines évènement est donc:
1. désactiver l'évènement par OFF_xxx
2. copier immédiatement MOUSE_?_POSITION dans des variables du genre xpos% et ypos%, spécifiques à ceyt évènement !
3. à partir de ce moment, utiliser uniquement ces variables pour le traitement de l'évènement
4. (... traitement spécifique de l'évènement ...)
5. réactiver l'évènement par ON_xxx

Désolé d'avoir été un peu llong, mais je voulais être le plus clair possible.

Bon, je veux bien, mais ça ne marche pas plus :

Code:

down:
   if mouse_x_position(500)>PSX% and mouse_x_position(500)<PSX%+120
      if mouse_y_position(500)>PSY% and mouse_y_position(500)<PSY%+120
         PIX%=mouse_x_position(500)-PSX%
         PIY%=mouse_y_position(500)-PSY%
         V3M%=color_pixel_red(520,PIX%,PIY%)
         if V3M%>0
            IDS%=1
            on_mouse_move 500,move
         end_if  
      end_if
   end_if
return

move:
  off_mouse_move 500
  if (mouse_x_position(500)-PIX%)>0 and (mouse_x_position(500)-PIX%)<1200
      if mouse_y_position(500)-PIY%>0 and (mouse_y_position(500)-PIY%)<454
        sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
  end_if
  on_mouse_move 500,move
return

up:
   if IDS%=1
      off_mouse_move 500
      PSX%=mouse_x_position(500)-PIX%
      PSY%=mouse_y_position(500)-PIY%
      IDS%=0
      PSX%=int(PSX%/41)*41+2
      PSY%=int(PSY%/41)*41+2
      if PSX%<0
         PSX%=2
      end_if
      if PSX%>1195
         PSX%=1191
      end_if
      if PSY%<0
         PSY%=2
      end_if
      if PSY%>460
         PSY%=452
      end_if
      sprite_position 510,PSX%,PSY%
   end_if
return

Et puis, il reste une question sans réponse :
Pourquoi si j'enlève le -PIX% d'avant le « <1200 », ça marche sans avoir à l'enlever avant le « >0 » ?

En tout cas, si je fais :

Code:

down:
   if mouse_x_position(500)>PSX% and mouse_x_position(500)<PSX%+120
      if mouse_y_position(500)>PSY% and mouse_y_position(500)<PSY%+120
         PIX%=mouse_x_position(500)-PSX%
         PIY%=mouse_y_position(500)-PSY%
         V3M%=color_pixel_red(520,PIX%,PIY%)
         if V3M%>0
            IDS%=1
            on_mouse_move 500,move
         end_if  
      end_if
   end_if
return

move:
   V1M%=mouse_x_position(500)-PIX%
   V2M%=mouse_y_position(500)-PIY%
   if V1M%>0 and V1M%<1200
      if V2M%>0 and V2M%<454
         sprite_position 510,V1M%,V2M%
      end_if
   end_if
return

up:
   if IDS%=1
      off_mouse_move 500
      PSX%=mouse_x_position(500)-PIX%
      PSY%=mouse_y_position(500)-PIY%
      IDS%=0
      PSX%=int(PSX%/41)*41+2
      PSY%=int(PSY%/41)*41+2
      if PSX%<0
         PSX%=2
      end_if
      if PSX%>1195
         PSX%=1191
      end_if
      if PSY%<0
         PSY%=2
      end_if
      if PSY%>460
         PSY%=452
      end_if
      sprite_position 510,PSX%,PSY%
   end_if
return

Là, ça marche sans avoir à mettre de off_mouse_move
Curieux, quand même !?!?


Quant au 2° exemple, je ne comprends pas.
Hier, il ne marchait pas avec la 1° formule
et marchait avec la 2°.
Et aujourd'hui, il marche avec les deux formules...
?????????????????????

Si je comprends bien, ce qui suit le bale  down:, c'est le traitement de ON_MOUSE_DOWN. Donc, OFF_MOUSE_MOVE n'a aucun sens ici - dans l'idéal, il faudrait coder comme suit:

Citation :

dim downx%, downy%
...
down:
 off_mouse_down nnn%   : ' nnn% représente le numéro de l'objet concerné (500 peut-être ?)
downx% = mouse_x_position(500)
downy% = mouse_y_position(500)
 if downx%>PSX% and downx%<PSX%+120
     if downy%>PSY% and downy%<PSY%+120
       PIX%=downx%-PSX%
       PIY%=downy%-PSY%
       V3M%=color_pixel_red(520,PIX%,PIY%)
       if V3M%>0
           IDS%=1
           on_mouse_move 500,move
       end_if
...
on_mouse_down nnn%

Ce sera également nettement plus rapide.

Quant à la partie qui "ne marche pas", je ne saurais pas dire pourquoi. L'extrait n'est pas suffisant pour tester chez moi...

Pour une meilleure compréhension, j'ai mis dans la Webdav jjn42 (chercher dans la rubrique Puzzles)
un programme qui marche (Essais de jeux de puzzle-02.bas)
et la version qui ne marche pas et qui nous préoccupe (Essai qui ne marche pas.bas)
Le but du jeu étant de déplacer la pièce 53 pour la placer sur la grille.
Peut-être cela permettra de mieux comprendre pourquoi l'une marche et pas l'autre ???

Ah, klaus, j'ai essayé avec ta dernière formule (voir Essai de jeux avec formule Klaus.bas)
Ca ne marche pas plus.

Je veux bien le télécharger, mais ton WebDav affiche:


Je n'ai pas trouvé "puzzles"...

Ah non, ça c'est les jeux
(tu a cherché dans le Webdav jjn4)
Il faut regarder dans le Webdav jjn42
(j'ai ajouté une version avec ta formule)

Ok, Merci. J'ai téléchargé et je vais regarder.

Premier test, avec la version qui "ne marche pas":
J'ai modifié la routine move: comme suit:

Code:

move:
  off_mouse_move 500
  if ((mouse_x_position(500)-PIX%)>0) and ((mouse_x_position(500)-PIX%)<1200)
      if ((mouse_y_position(500)-PIY%)>0) and ((mouse_y_position(500)-PIY%)<454)
        sprite_position 510,mouse_x_position(500)-PIX%,mouse_y_position(500)-PIY%
      end_if
  end_if
  on_mouse_move 500,move
return

ET ça marche ! Pas d'erreur de syntaxe, et la pièce se déplace correctement.

Et ainsi, c'est encore plus sûr:

Code:

move:
  off_mouse_move 500
  movex% = mouse_x_position(500)
  movey% = mouse_y_position(500)
  if ((movex%-PIX%)>0) and ((movex%-PIX%)<1200)
      if ((movey%-PIY%)>0) and ((movey%-PIY%)<454)
        sprite_position 510,movex%-PIX%,movey%-PIY%
      end_if
  end_if
  on_mouse_move 500,move
return

avec "dim movex%, movey%" inséré devant "label ...".
Ca marche trèe bien.

La version Puzzle-02 marche très bien.

La version "formule Klaus" a besoin d'une correction en ligne 64, comme suit:

Code:

  on_mouse_down 500,down

et ça marche très bien.

Puis, j'ai sécurisé et optimisé la version "formule Klaus", et ça donne ça:

Code:

down:
  PIX%=mouse_x_position(500)
  PIY%=mouse_y_position(500)
  if PIX%>PSX% and PIX%<PSX%+120
      if PIY%>PSY% and PIY%<PSY%+120
        PIX%=PIX%-PSX%
        PIY%=PIY%-PSY%
        V3M%=color_pixel_red(520,PIX%,PIY%)
        if V3M%>0
            IDS%=1
            on_mouse_move 500,move
        end_if 
      end_if
  end_if
return

move:
  off_mouse_move 500
  V1M%=mouse_x_position(500)-PIX%
  V2M%=mouse_y_position(500)-PIY%
  if V1M%>0 and V1M%<1200
      if V2M%>0 and V2M%<454
        sprite_position 510,V1M%,V2M%
      end_if
  end_if
  off_mouse_move 500,move
return

Le fonctionnement en est inchange. Mais, et c'est l'important: l'évènement MOVE est protégé. Cela ne semble pas influer dans le code tel qu'il est actuellement, mais en évoluant, le traitement du MOVE pourrait très bien devenir plus complexe et durer quelques milli-secondes de plus. Or, dans ce cas, l'évènement MOVE suivant pourrait très bien se produite AVANT la fin du traitement en cours, et BOUM...

Enfin, regarde le code ci-dessus, tu vois le principe.

Ah oui, autant pour moi,
tout marche !
C'était donc des erreurs de ma part...
Merci à tous !

Klaus a écrit:

Désolé d'avoir été un peu long, mais je voulais être le plus clair possible.

Non, ne soit pas désolé, tes explications sont toujours très enrichissantes et une piqûre de rappel de l’art de la programmation est toujours utile. Merci Klaus !

JJN4 a écrit:

Ah oui, autant pour moi...

=> Syntax Error ! Correction : "Ah oui, au temps pour moi..."

JJN4 a écrit:

Je me suis mis à utiliser Élip

Merci JJN4 !



Astuce avec EliP :

Recherche rapide d’une expression : il suffit de cliquer sur un mot puis de naviguer avec les touches F3 ou F4.
F3 : occurrence suivante
F4 : occurrence précédente

Il est également possible de sélectionner avec la souris un ensemble de caractères puis F3 ou F4 pour rechercher cette sélection.


Allez, avant d’aller dormir, une autre astuce : le raccourci Ctrl + s permet un enregistrement instantané du code source.

Bonne nuit à tous !  

Merci, Marc !

Pour info "linguistique", lire ceci:
https://www.projet-voltaire.fr/regles-orthographe/au-temps-pour-moi-ou-autant-pour-moi/
ou encore:
https://www.lalanguefrancaise.com/orthographe/autant-au-temps-pour-moi
Faites vos propres conclusions...

Ah, merci Klaus !
Car donc, c'est contestable !
Moi, j'ai bien la forme Autant... !

Et merci aussi à Marc pour ses bonnes astuces de l'utilisation d'Élip !
C'est bien utile !
Si il existe encore d'autres astuces comme celles-là,
n'hésite pas à les préciser !
J'apprécie Élip en particulier pour sa transparence face aux antivirus !
Mais je suppose qu'il a encore d'autres qualités ?!?!

JJN4 a écrit:

J'apprécie Élip en particulier pour sa transparence face aux antivirus !

Merci, mais je n’y suis pour rien ! EliP n’est qu’un source classique en Panoramic.
C’est le Make_Exe.exe conçu par Jack qui crée des .exe que les antivirus tolèrent mieux.

JJN4 a écrit:

Si il existe encore d'autres astuces comme celles-là,
n'hésite pas à les préciser !

En voici une autre :

Un clic sur un mot-clé puis la touche F1, ouvrira l’aide à la page du mot-clé en question.

On peut taper aussi les premières lettres d’un mot-clé puis F1 pour ouvrir l’aide au bon endroit.



La version d'EliP à jour est la v6.06 du 15/11/2022, disponible dans mon WebDAV.

Les anciens liens de l'hébergeur e-nautia ne fonctionnent plus, je vais les changer...

Superbe, les astuces, j'adore !

Marc a écrit:

C’est le Make_Exe.exe conçu par Jack qui crée des .exe que les antivirus tolèrent mieux

Mais alors, petite question :
Si c'est grâce à Jack qu'Élip est bien toléré par les antivirus,
pourquoi ne l'a t-il pas fait pour l'éditeur Panoramic ???

jjn4 a écrit:

Si c'est grâce à Jack qu'Élip est bien toléré par les antivirus,
pourquoi ne l'a t-il pas fait pour l'éditeur Panoramic ???

Pour 2 raisons:
- l'éditeur Panoramic n'utilise pas Make_Exe, car Make_Exe est fait précisément pour ne pas être utilisé par l'éditeur Panoramic, mais avec des éditeurs alternatifs,
- Elip 6.06 utilise une version de Make_Exe du 17 décembre 2019 qui, je ne sais pas pourquoi, n'attire pas les foudres des anti-virus.

Jack a écrit:

...qui, je ne sais pas pourquoi, n'attire pas les foudres des anti-virus

Elle est bien bonne celle-là !
Si le maître ne comprend pas...

Eh bien finalement, je ne sais pas si les antivirus ont changé,
mais maintenant, ils n'acceptent plus les programmes édités par Elip,
c'est bien embêtant, ça,
parce que ça donne au langage panoramic un côté peu fiable !

Je pense que ça ne vient pas de ELIP, mais plutôt de l'interpréteur Panoramic qui est intégré dans l'exécutable généré via Make.exe. En effet, des exécutables embarqués dans un autre cachent souvent des virus...

Pour ma part, j'utilise IOBit Malware Fighter comme antivirus, et il n'y trouve rien à dire? Par contre, Windows Defender ou certains autres antivirus, c'est une autre affaire...

J'utilise Windows defender de Windows 8 pour mon ordi le plus lent,
et là, ça ne pose pas de problème.
Mais pour le plus rapide, c'est Windows defender de Windows 11
et là, oui, ça pose problème.
Et j'ai eu un contact récemment avec un ordinateur défendu par Avast,
et là encore, ça a été l'affolement général de l'ordi.

Petite question :
Qu'est-ce que tu veux dire par :
« des exécutables embarqués dans un autre » ?

Alors, tu n'as guère que 2 choix:
- signaler le cas comme faux positif au fournisseur du antivirus avec un exempaire du exe en pièce jjointe
-mettre le programme dans la liste blanche de l'antivirus

Klaus a écrit:

signaler le cas comme faux positif au fournisseur de l'antivirus avec un exemplaire du exe en pièce jointe

Mais alors, il faudrait lui envoyer un exemplaire à chaque fois qu'on fabrique un nouvel exécutable.
Ce serait sans fin !
Pour ce qui est de :
« mettre le programme dans la liste blanche de l'antivirus »
C'est ce que je fais toujours,
mais quand je transfère un programme sur une clé USB
en oubliant de désactiver l'antivirus... c'est panique à bord !