Un phénomène curieux

Code:

WIDTH 0, 600: HEIGHT 0, 600: COLOR 0,128,255,255
2D_PEN_COLOR 0,0,0: 2D_FILL_COLOR 255,0,0: 2D_FILL_DIAGONAL_CROSS
wait 100
2D_RECTANGLE 50,5,550,540
END

Si je mets le wait 100 en commentaire, mon rectangle n'est plus dessiné (on dirait qu'il n'a pas le temps) ?

Effectivement, très étrange!
J'ai aussi vu que parfois des instructions étaient "oubliés" ou plutot: "dépassés". C'est pour ça que pour certains logiciels, j'avais changé l'ordre des objets et alors ça marchait. Sans doute pour la même raison que tu as observé: 'pas le temps'.
Heureusement, avec seulement
wait 1
ça marche aussi a nouveau, donc ton programme ne sera pas trop rallenti!

si ça marche avec wait 1 c'est tout aussi bizarre^^

Il n'y a rien de bizarre là dedans. Si vous mettez la commande display à la place de wait, le rectangle est dessiné. Display, équivaut à wait 1 et permet de mettre à jour l'affichage à l'écran. Voir l'aide sur display pour plus d'info.

J'avais constaté le même phénomène sur mon 'incollables' sans un wait 1, les pions ne s'affichaient pas ... en le mettant, ça marchait ...

ouais, fallait juste savoir que wait équivaut à display :/

C'est vrai que ce n'est pas très gênant, un wait 1 ou un display suffit, mais d'abord il faut le savoir, et puis c'est curieux que ça se produise avant le END, alors que la surveillance des événements n'a pas encore commencé, on en est encore à la mise en place des éléments.

Dans les conseils, on peut lire qu'il faut mettre DISPLAY après une coloration par exemple (Aide / conseils / paragraphe 3.3). Cette instruction a été créée uniquement pour faire une pause pendant laquelle Windows a le temps d'afficher et de colorer des choses.

Mais j'interviens pour un autre sujet que je lis très souvent dans le forum:

Citation :

c'est curieux que ça se produise avant le END, alors que la surveillance des événements n'a pas encore commencé

C'est quelque chose de récurrent. Je suis pourtant intervenu souvent sur ce sujet et le malentendu persiste.
Je vais faire une clarification dans la rubrique "Tutoriels et éclaircissements".
Voir la discussion d'Avril 2010 : https://panoramic.1fr1.net/t753-appel-d-evenement-en-dehors-du-end

L'instruction END n'a rien à voir avec la gestion des événements.
L'instruction END n'existe que pour arrêter l'exécution et empêcher l'exécution de continuer en séquence et d'aller exécuter le traitement d'un événement dans le cas où on met le traitement des événements après le programme principal.

PANORAMIC est un langage Basic et lors du lancement, l'exécution commence à la première ligne du source. C'est pourquoi il est commode de commencer un programme en définissant l'environnement par la création des objets, leur positionnement, leurs dimensions, à quels événements ils devront réagir. Dans ce cas, on a un programme "principal", qui débute à la première ligne du source. Or, quand tout l'environnement a été décrit, il faut arrêter ce programme principal pour qu'il n'aille pas éxécuter du code réservé aux traitement des événements.
C'est à cela que sert le END.

Si on prend le schéma le plus utilisé, il y a besoin d'un END:

Code:

label clique:rem on définit un label
button 1:rem on définit un objet
top 1,50:left 1,100:rem on le positionne
on_click 1,clique:rem on le fait réagir à un événement clic
rem on doit arrêter le programme principal ici, sinon on va aller exécuter "clique"
rem c'est pourquoi on met END
end

rem on met ici le traitement du clic
clique:
caption 1,"clic"
return

Dans cet exemple, si on n'avait pas mis de END, l'exécution aurait continué jusqu'à l'instruction RETURN et on aurait une erreur du type : RETURN trouvé et il n'y a pas eu de GOSUB. C'est le seul rôle du END: arrêter le programme principal pour que l'exécution n'aille pas exécuter le traitement réservé pour les événements.

Mais si on décide le mettre les traitements d'événements AVANT de définir les objets, on n'a plus besoin de END car l'exécution s'arrête naturellement à la dernière ligne du source !

Code:

label alenvers,clique
goto alenvers

rem on met ici le traitement du clic
clique:
caption 1,"clic"
return

alenvers:
button 1:rem on définit un objet
top 1,50:left 1,100:rem on le positionne
on_click 1,clique:rem on le fait réagir à un événement clic

En rsumé: L'instruction END n'a rien à voir avec la gestion des événements.

Un événement est actif dès l'instruction qui le définit: ON_CLICK, ON_CHANGE, etc...
Et cet événement reste actif après l'exécution du END.
Après l'exécution du END, le programme principal est arrété, mais la gestion des événements continue à être active.

Merci Jack pour ces éclaircissements, c'était évidemment un malentendu de ma part, je pensais qu'aucun événement n'était traité avant le End.
Bon, eh bien je n'ai plus qu'à réviser ma philosophie de Panoramic à la lumière de tes explications.
Merci en tout cas.

Il n'empêche que je reste perplexe...
Si je reprends mon petit programme de là-haut:

Code:

WIDTH 0, 600: HEIGHT 0, 600: COLOR 0,128,255,255
2D_PEN_COLOR 0,0,0: 2D_FILL_COLOR 255,0,0: 2D_FILL_DIAGONAL_CROSS
2D_RECTANGLE 50,5,550,540
END

je ne vois toujours pas ce qui empêche le 2D_RECTANGLE de s'exécuter... que ça se fasse avec retard, je veux bien, parce que c'est du graphique et que c'est long à dessiner, mais ce fameux rectangle devrait finir par apparaître, le programme n'a plus rien d'autre à faire.
Mais qu'on fasse l'impasse sur une instruction sous prétexte que ça va trop vite, ça dépasse mon entendement. Dans mon idée les instructions s'exécutent en séquence, la suivante quand la précédente est exécutée.

Si je mets un stop après le 2D_RECTANGLE, je vois le rectangle apparaître fugitivement avant d'être recouvert par le fond du Form 0...

Et ce code marche:

Code:

WIDTH 0, 600: HEIGHT 0, 600: COLOR 0,128,255,255
2D_PEN_COLOR 0,0,0: 2D_FILL_COLOR 255,0,0: 2D_FILL_DIAGONAL_CROSS
display
2D_RECTANGLE 50,5,550,540
END

Même ceci marche:

Code:

WIDTH 0, 600: HEIGHT 0, 600
COLOR 0,128,255,255
display
2D_PEN_COLOR 0,0,0
2D_FILL_COLOR 255,0,0
2D_FILL_DIAGONAL_CROSS
2D_RECTANGLE 50,5,550,540
END

Pourquoi ? parce que le dessin se fait, au final, de façon ASYNCHRONE par une routine de service de Windows. Il s'agit de la commande COLOR. Le programme Panoramic passe à l'instruction suivante alors que la routine de service Windows n'a pas encore fini d'exécuter ce qu'elle doit faire pour ce qui a été demandé par COLOR. Donc, le résultat des commandes suivantes, et en particulier RECTANGLE, est bien affiché, mais écrasé par le traitement plus long de ce qui se déroule en arrière-plan pour satisfaire la demande de COLOR.

C'est comme si tu déposais un chèque à ta banque et tu voulais retirer l'arget tout de suite en espèces. Problème: le compte n'est pas crédité. Il faudra attendre le délai d'encaissement avant de tirer des espèces. Et c'est la commande DISPLAY qui le fait - la doc le dit clairement.

Tout à fait.
Bien que les commandes soient traitées en séquence par des appels à des API de Windows, Windows met toutes les commandes graphiques en file d'attente et les traite en fonction de leur durée d'exécution.
Il traite les plus rapides d'abord et COLOR est une commande qui prend du temps : il va l'exécuter en dernier.
C'est pourquoi j'ai codé DISPLAY qui force Windows à exécuter la commande.

Windows fait ce qu'il veut et pas seulement dans le domaine graphique. Il arrive aussi par exemple, qu'il change des numéros de ports d'entrées-sorties !
Ce système d'exploitation monopolistique plein de rajouts et de patchs et fait sans vision d'ensemble est une catastrophe.

Dans le domaine militaire, où on a besoin de fiabilité et d'efficacité, il serait impensable d'utiliser Windows.
Toutes les applications sur lesquelles je travaille sont sous LINUX qui est d'une toute autre rigueur.
Autre chose: tous les serveurs du net y compris les serveurs de la société Microsoft tournent sous LINUX ...

Eh bien, il me paraissait logique que toutes les commandes soient traitées dans l'ordre chronologique de leur arrivée (hors interruptions), séquentiellement.
Je vois bien que ce n'est pas forcément le cas (en tout cas pour les commandes qui font appel à des fonctions windows), et je vois mieux l'utilité du Display !

J'ai travaillé autrefois sur un système temps réel (avec un os dédié), effectivement il me semble que là non plus windows n'aurait pas été très approprié !

Merci à tous les deux pour ces précisions.

Citation :

tous les serveurs du net y compris les serveurs de la société Microsoft tournent sous LINUX ...

Dire qu'il a inondé le monde de son windows :/

En plus, une pâle copie de GEM.

J'avais ce genre de probleme (saut de ligne) sur un viel Amstrad.Je corrigeais en doublant,ou triplant la ligne concernée.Ce qui,bien sur, n'est pas toujours possible de faire.