Version instantanée du 10 décembre 2010

Comprendre se qui se passe, je n'ai pas les outils pour ça.
Mais maintenant que cela fonctionne, l'aide va aux oubliettes.

Il faudrait peut-être un jour faire un roman pour Panoramic. Il n'y aura pas de sexe, mais que de péripéties. Les déboires et les satisfactions sont monnaie courante.

Merci pour tes remarques.

Merci Maitre klaus, je vais regarder tes liens, car j'aimerais bien pouvoir lancer panoramic derniere version en double-cliquant sur mes fichier "bas".

Pour tous ceux qui s'intéressent à l'objet CONTAINER:

Cet objet est bien plus intéressant que la modeste description de Jack laissant supposer. En effet, on peut utiliser beaucoup de fonctions avec cet objet:
- évidemment positionnement et dimensionnement, ainsi que de servir de parent pour d'autres objets: ça, c'est la partie évidente.
Mais aussi:
- donner un libellé avec tous les attributs possibles par
CAPTION, FONT_NAME, FONT_SIZE, FONT_COLOR, FONT_BOLD, ...
- donner un hint (!) au survol, avec HINT, et désactiver ce hint avec HINT_HIDE
- même cliquer le container et déclencher une routine évènement par ON_CLICK, contrairement au CONTAINER_OPTION qui n'est pas cliquable
- on peut lui allouer l'espace total de la form par FULL_SPACE ce qui est particulièrement intéressant pour des forms sans bord - on peut ainsi faire un bord simple très facilement, au lieu de dessiner des rectangles.

Oui, c'est un objet qui va me servir pas mal à moi
l'objet container

En améliorent mon programme (il n'est pas fini), je me suis retrouvé avec le même problème que depuis hier soir.

Mais en voulant voir une chose sur le net, je n'arrivais plus à me connecter. En cliquant sur état (pour la connexion) et réparé, un message est apparu en me disant que je n'avait plus de mémoire cache, je ne me souvient plus du nom.
J'ai refais un démarrage, et depuis cela remarche.
Je n'ai pas de qualification pour savoir si la fonction chain a un rapport avec cette mémoire, vu qu'avec l'éditeur Panoramic mon programme fonctionnait.

J'ai utilisé l'astuce de Sergeauze et ça marche impeccable !

J'ai renommé panoramic_editor.exe et quand on fait "ouvrir avec" sur un fichier "bas" windows liste bien le nouveau nom de panoramic et donc on peut l'associer aux fichiers "bas".

Super cette astuce mais c'est quand même bizarre

RAPPORT SUR LES PROBLÉMES QUE J'AI EU AVEC MON "pré-processeur" sile mot est exact
Je viens de trouver la raison pour laquel je me trouve avec une erreur en cours de programme avec l'erreur quelque chose comme: nom déjà définie en ligne 3, alors que j'en suis bien loin.

Mon programme de lancement est un programme Panoramic qui est un exécutable, et fonctionne avec l'instruction CHAIN.
Donc ce programme récupère d'une façon ou d'une autre celui que je veux lancer.
Ce programme est en même temps une boite à outils, qui me permet pleins de choses. Il a un compte à rebours, qui lorsqu'il arrive à zéro lance le programme. Je peux courcircuiter ce compte à rebour, mais je peux aussi faire d'autre chose. Comme lancer un débogueur, faire une copie intermédiaire du programme que je veux lancer, me servir d'un autre programme comme celui qui me permet de contrôler les boucles de end_if, et plein d'autre-choses.

Or ce programme qui justement a un compte à rebours, a un timer qui fait cette fonction. Lorsqu'il arrive à zéro, je le désactive, et je passe à l'instruction CHAIN pour lancer mon programme.
Selon les circonstances, il arrive qu'il ne soit pas désactivé.

Normalement la fonction chain remplace le lanceur (que j'ai appelé préprocesseur), et je pensais qu'il ne devrait pas rester de traces du lanceur. Il n'en est rien. J'ai remarqué aussi une chose, avec ce lanceur, j'exécute ce que je fais en ce moment le programme qui pour fonction de remplacer les fonctions chaines que je mets au point, ainsi que les dims locaux, ce que vous avez déjà vu. Pour la mise au point je me sers de la dll de Klaus afin que la fenêtre qui est ouverte avec le rendu des variables, reste au dessus des autres fenêtres. Et bien le programme générée a exactement la même fenêtre que celle citée, à la différence que la dll de Klaus concernant la mise en avant de la fenêtre n'est pas présente. Et bien cette nouvelle fenêtre reste dessus. Je suis fautif vu que je viens de voir que dll_off est après l'instruction chain.

En résumé, lorsque l'on se sert d'une instruction CHAIN, il faut bien arrêter les timers ainsi que les dll en cours.
Le fautif ici c'est moi, et je fais ce rapport pour bien connaitre cette instruction CHAIN, et éviter les désagréments que j'ai eux. Le plus dur a été de comprendre le pourquoi.

Merci, Cosmos70 ! Grâce à ta brillante analyse, je viens de comprendre pourquoi j'avais des problèmes intermittants avec un de mes programmes !

La démonstration est magistrale et limpide: CHAIN ne supprime pas toutes les traces du programme précédent ! DLls, timers, même des lignes de source restent - sinon, la routine d'évènement du timer "oublié" ne pourrait pas s'exécuter et provoquer une anomalie. A la limite, une violation de mémoire pourrait être acceptée comme conséquence logique - on se dirait: zut, il y a une routine qui manque, j'ai donc oublié de désactiver quelque chose.

Citation :

La démonstration est magistrale et limpide: CHAIN ne supprime pas toutes les traces du programme précédent

Je m'interroge si c'est un dysfonctionnement ou pas.
Le but de CHAIN est de chaîner l'exécution d'un source avec le programme en cours.
La logique voudrait que TOUT du programme appelant soit supprimé.
A voir.

Oui, je pense aussi que tout du programme appelant devrait avoir été désactivé, et qui plus est, même effacé ou supprimé - source, objets, variables, évènements, fichiers ouverts... Mais en apparence, ce n'est pas le cas.

EDIT

J'ai fait quelques textes, et le problème semble complexe. En effet, avec un programme simple, cela ne se produit pas. J'ai fait deux petits modules avec la même variable et un timer lancé dans le premier module, et tout se passe bien.

Voici chain_1.bas:

Code:

label tim

dim text%

timer 1 : timer_interval 1,1000
on_timer 1,tim
timer_on 1
chain "chain_2.bas"

tim:
print "timer dans chain_1"
return

et voici chain_2.bas:

Code:

dim test%

print "Chain_2.bas !"

J'ai une version chain qui copie le programme à partir du clipboard, et tout se passe bien. C'est également vrai lorsqu'il lit un fichier.

La version avec le timer me posait le problème de variables qu'il relisait. J'ai modifier dans le préprocesseur, la fonction timer, où je l'ai stoppé, et supprimé avec delete. A partir de là, il n'y a plus de problème.

Par contre avec la dll qui met en avant une fenêtre, cette fonction ne se démet pas. Donc un dll.off ne suffit pas pour désactiver ce "sur-fenêtrage", et se reporte sur le programme suivant. Donc si cela est gênant, il faut avant de passer au programme chainé, désactiver la fenêtre avant de faire dll_off N.
Depuis que j'ai revu ce timer, le programme semble fonctionner normalement. Je ne vais pas refaire en sens inverse les essais, mais dans mon cas, je me demande maintenant si timer étant réglé pour agir toutes secondes, si le programme généré, lancé en court-circuitant le compte à rebours, n'aurait pas fonctionné normalement une fois le compte à rebours fini et qui aurait si il y a encore des traces du programme précédent désactivait le timer, puisque c'était prévu. Arrivé à zéro le timer se désactivait.

Si il y a des testes à faire, c'est dans ce sens qu'il faudrait voir.
Je quitte, je pars.

Je viens simplement de faire un essai avec le chargeur, de mettre la fenêtre en mode normal concernant la dll de Klaus qui permet de mettre au premier plan une fenêtre. Je le fais juste avant de mettre dll_off et me servir de chain. Et là le programme qui est lancer à de nouveau une fenêtre normale. Je ne sais pas se qui se passe réellement , mais il ne s'agit d'un programme à l'autre concernant l'objet:
Je fais la même chose avec les même paramètres, sauf que pour le premier programme, il s'agit de memo 5, et celui qui est lancé est memo 1.
Le memo 1 récupère les paramètres du programme chain qui est memo 5.

Par contre je n'arrive plus avec le timer à provoquer le message d'erreur.

@Jack:

Je reviens sur la commande CANCEL_CLOSE.

Tu as dit qu'elle était plus difficile à coder que prévue. J'ai fait un petit programme delphi, contenant le code suivant:

Code:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
if MessageDlg('Vraiment fermer ?',mtConfirmation,[mbOK,mbCancel],0)=mrOK then
    action := caFree
else
    action := caNone;
end;

Et le clic sur la croix rouge peut simplement être annulé, sans autre conséquence.

J'imagine que la routine évènement ON_CLOSE déclarée dans Panoramic est appelée à la suite de l'évènement on_close de Delphi, avant le "end;" de cette routine. Pourrait-on imaginer que la commande CANCEL_CLOSE charge la valeur caNone dans le paramètre Action de la procédure xxx.FormClose, de sorte que le RETURN de la routine Panoramic appelée par l'évènement ON_CLOSE de Panoramic retourne dans la routine xxx.FormClose ce qui annulerait automatiquement la fermeture de la fenêtre ?

Excuse-moi si je suis complètement à-côté, je voulais juste ouvrir une piste de réflexion.

Citation :

J'imagine que la routine évènement ON_CLOSE déclarée dans Panoramic est appelée à la suite de l'évènement on_close de Delphi, avant le "end;" de cette routine.

Eh bien non, c'est justement ça la difficulté. L'événement lié à ON_CLOSE, comme tous les événements, peut s'empiler dans la pile des événements et être exécuté bien plus tard alors que Windows a fermé la fenêtre depuis longtemps!

Car le clic sur l'icone croix de la fenêtre, à la différence d'un clic sur un bouton ou sur un autre objet, provoque systématiquement la fermeture par Windows de la fenêtre, indépendemment du traitement de cet événement: on a beau mémoriser qu'il y a eu un événement "on_close", Windows ferme bel et bien la fenêtre, même s'il y a la commande CANCEL_CLOSE dans le traitement différé de cet événement !

Il faut donc avoir mémorisé qu'il y a eu ou pas une commande d'annulation CANCEL_CLOSE pour fermer ou pas la fenêtre et avoir également mémorisé quelle fenêtre il ne faut pas fermer. Tout cela n'est pas été prévu dans le traitement actuel de la pile des événements.

Excusez moi si je dis une chose id.., mais ne serait-il pas plus simple de faire un bouton, ayant l'allure de la case fermeture, et qui resterai en permanence dessus la case de fermeture. C'est lui qui prendrait le relais.

Je parle évidemment d'un nouvel objet. L'objet button ne pouvant s'afficher sur la barre du haut (comme button_trapclose). Je m'avance peut-être de trop.

Eh bien, dans le petit bout de programme que j'ai fait, on peut bel et bien annuler l'évènement de fermeture. Car lorsque Windows déclenche cet évènement, c'est par l'intermédiaire d'une "procedure" Delphi - du moins, pour chaque fenêtre (form), on peut définir une procédure on_close. Son dernier paramètre est un code retour que la procédure appelée doit fournir pour valider ou annuler l'action de fermeture, comme c'est montré dans mon exemple.

Ne pourrait-on pas envisager d'appeler le sous-programme Panoramic on_close directement, AVANT de laisser la procédure On_close Delphi se terminer, en ignorant la pile des évènements - ce serait alors le RETURN du sous-programme ON_CLOSE de Panoramic qui reprendrait le cours normal, à savoir finir l'exécution de la routine on_close Delphi. Et si la commande CANCEL_CLOSE a été effectuée, la fameuse variable de retour aura été modifiée et la fermeture est ignorée, et parallèlement, le traitement habituel de la pile d'évènements continue.

Avec un tel mécanisme, ce serait possible; sinon, si l'on ne peut pas lancer la routine ON_CLOSE Parnoramic directement à partir de la routine on_close Delphi avant de finir cette dernière, il n'y aura pas moyen d'annluer une fermeture de fenêtre. Ce serait dommage, car justement, dans Delphi, c'est prévu. Mais, tu as raison, si l'évènement est traîté de la même manière que les autres: mise sur la pile des évènements de Panoramic, puis fin de l'évènement côté Delphi, c'est cuit. Il faut pouvoir exécuter, hors pile, la routine on_close de Panoramic AVANT la fin de la routine on_close de Delphi.

EDIT

Une autre façon d'intercepter la fermeture, est la suivante:

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, WinTypes, WinProcs, StdCtrls;

type

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    public
    procedure WMSysCommand(var Msg: TWMSysCommand); message WM_SYSCOMMAND;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.WMSysCommand;

begin
  if (Msg.CmdType = SC_CLOSE) then begin
    if MessageDlg('Fermer vraiment ?',mtConfirmation,[mbOK,mbCancel],0)=mrCancel then
      Msg.CmdType := SC_RESTORE;
  end;
  DefaultHandler(Msg);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
    application.Terminate;
end;

end.

On pourrait imaginer une commande à effectuer AVANT de fermer la fenêtre (en configuration en création, dynamiquement en cours de programme, ...) pour prédéfinir l'action à effectuer lorsque la fenêtre doit se fermer par la croix rouge:
CLOSE_ACTION N,P
N = numéro d'objet de la form
P = code action
0 = rien à faire, fermer simplement la fenêtre
1 = utiliser ON_CLOSE tel que c'est implémenté actuellement
2 = interdire totalement la fermeture
3 = demander confirmation

Cela agirait exactement comme une commande FONT_SIZE N,P. La valeur de ce paramètre est stockée dans une variable interne associée à la form, et dont la valeur par défaut est zéro, bien sûr. ET la ligne

Code:

    if MessageDlg('Fermer vraiment ?',mtConfirmation,[mbOK,mbCancel],0)=mrCancel then
      Msg.CmdType := SC_RESTORE;

serait remplacée par quelque chose comme ceci:

Code:

case (variable CLOSE_ACTION de la form) of
0:  { rien à faire - laisser la fenêtre se fermer }
1:  { appliquer le mécanisme ON_CLOSE actuel }
2: Msg.CmdType := SC_RESTORE;  { interdire la fermeture}
3: if MessageDlg('Fermer vraiment ?',mtConfirmation,[mbOK,mbCancel],0)=mrCancel then
      Msg.CmdType := SC_RESTORE;
end;

On pourrait ainsi courtcircuiter le mécanisme de la pile des évènements pour cet évènement particulier.

J'ajoute que de la même manière, on pourrait intercepter et interdire les boutons Minimiser et Maximiser, en testant sur le code SC_MINIMIZE et SC_MAXIMIZE...

Petite réflexion
J'avais lu ton post, et n'étant pas à la hauteur de ton programme, je suis resté en dehors.
Ayant eu hier à jeter un coup d'oeil sur Justbasic, que je ne me suis servi depuis longtemps, je pense savoir pourquoi il y a problème avec Panoramic.

Déjà au départ, en dehors de la programmation, je ne connais rien sur Panoramic et sur JustBasic. Le fonctionnement interne, je ne le connais pas. Jack, depuis un an et demi que j'ai commencé avec Panoramic, n'a jamais donné d'information interne sur son logiciel. Donc il est clair que ce ne sont que des suppositions, et que je ne fais qu'une analyse d'après ce que je constate, et non en désassemblant son logiciel. Si je me plante, Jack dans son coin doit bien rire, ou penser à bien des choses à mon égard. Tans pis!

Lorsque tu fais un programme personnel, tu peux l'adapter à ta guise, et te servir des possibilités du logiciel (ici Delphi).
Mais Jack en codant son basic, doit non seulement faire un logiciel pour lui, mais un logiciel qui se transforme continuellement selon chaque utilisateur. Il a adopté un principe dans sa conception pour le fonctionnement des appels d'évènement. Il y a un an, suite à différentes remarques de notre part, qui était que chaque fois que l'on cliquait sur un évènement, le sous programme, que le programme exécutait était escamoté (n'allait pas au return) et se lançait sur la fonction du nouveau clic. Pour résoudre ce problème, il n'y avait que inactive d'objet qui permettait d'empécher ce problème, et de rétablir au moment du return.
A partir de là, Jack a donné une version qui depuis fonctionne avec une enfilade des appels dans une file d'attente. Là je ne vais pas demandé à Jack de revenir en arrière.

Mais je vais faire un parallèle avec Jusbasic. Avec ce langage qui est (à mon avis moins puissant que Panoramic, si ce n'est que l'impression, et la communication avec les ports sont prévus), on peut intercepter la fermeture d'une fenêtre, et aussi stopper un programme avec >CTRL Pause<

Oui mais comment est-ce possible. Et bien je pense que cela se fait sur 2 niveaux d'évènements
Dans Justbasic, les commandes d'appel se font d'une autre façon:


open "Inkey$ example" for graphics as #graph

print #graph, "when characterInput [keyPressed]"
print #graph, "trapclose [quit]"

Elles se font à travers d'une instruction print, et je pense qu'il y a une interception simple au départ pour tester des évènements qui arrivent et agir en conséquence, et ensuite on a la queue de file des instructions PRINT, qui possèdent les autres commandes d'appel évènementielle.
Dans ce cas de figure, le clic sur une case de fermeture est tout de suite intercepté, et si une programmation de l'interruption est faite, comme ici, si la case "trapclose" est pressée, on va à l'étiquette [quit] qui fait ce qu'il veut.

A voir si Jack trouve une solution, soit pour mettre en avant interruptions prioritaires. Si oui, il serait également possible de stopper un programme en boucle.

Je peux faire un autre parallèle, avec mon mode trace.
Comme je l'ai dit, je peux stopper tout boucle, à partir du moment où une boucle se fait sur plusieurs lignes.
Ainsi si j'ai une boucle du genre: for a%=1 to 10000: a%=1:next a% il est évident qu'il y a une erreur de programmation, et cette boucle je ne peux pas l’arrêter, car j'ai pas voulu la décortiquer, en séparant chaque instruction de la ligne. Cela eut été possible, mais je ne l'ai pas fait.

Mais la même formule écrite autrement:
for a%=1 to 10000
a%=1
next a%
ce morceau de programme, en cliquant sur stop, je l'intercepte.
Disons que Jack à fait son logiciel selon Le premier exemple, et disons que Justbasic est le second exemple.

Pour ma part, j'ai envisagé, et je ne sais pas si une fenêtre Windows le permet, de faire un nouvel objet de bouton pour ce cas de figure. Si c'est possible, afin de répondre à tout ceux qui souhaitait avoir d'autre type de barre de fenêtre, peut-être des barres à la demande en remplacement du bouton seraient une autre solution.

Si je me plante sur tout, j'accepte les oeufs pourris.