Commande EXECUTE

Un problème que j'avais déjà soulevé, il me semble, c'est le fait que la commande EXECUTE soit passante, c'est à dire que Panoramic lance l'exécution du programme externe, mais rend immédiatement la main au programme appelant, à la ligne suivante.
Ce qui est très gênant si on attend le résultat du programme appelé.

Un exemple (liste des fichiers d'un répertoire):

Code:

EXECUTE "Command.com /c DIR C:\Repertoire\*.txt [options] >C:\Fichdir.txt"
File_OpenRead n, "C:\Fichdir.txt"
    File_ReadLn n, a$ ... etc ...

Si le DIR est un peu long à s'exécuter,
- soit le fichier Fichdir.txt existait déjà, auquel cas on récupère son ancien contenu, sans moyen de le savoir.
- soit il n'existait pas, et on tombe en erreur à l'ouverture (fichier n'existe pas, c'est à dire il n'a pas eu le temps d'être créé).
Si je mets avant l'EXECUTE:

Code:

IF File_Exists("C:\Fichdir.txt") = 1 Then File_Delete "C:\Fichdir.txt"
EXECUTE etc...
While File_Exists("C:\Fichdir.txt") = 0: End_While
File_OpenRead n, "C:\Fichdir.txt"

A la sortie du While, le fichier est censé exister, mais en fait il n'est pas encore écrit physiquement sur le disque, et on récupère quand même une erreur à l'OPEN (erreur 93: File does not exist).

Alors il faut mettre des Wait complètement arbitraires (très longs pour couvrir tous les cas), ce qui ralentit le programme.
Ce n'est pas très logique non plus que File_exists réponde oui, alors que File_open qui suit dit non.

La solution serait d'avoir deux options dans EXECUTE: Passant (le programme se poursuit), ou Bloquant (on attend la fin d'exécution du programme appelé). Ou mieux, une autre fonction EXECUTE qui serait bloquante (EXECUTE_PASSANT et EXECUTE_WAIT).

En Basic classique, ce devait être systématiquement avec attente, puisque je n'ai jamais rencontré ce problème.

Oui çà serait pas mal

Citation :

EXECUTE "Command.com /c DIR C:\Repertoire\*.txt [options] >C:\Fichdir.txt"

Peut-tu m'expliquer EXECUTE "Command.com /c. çà sert à quoi ?

J'en profite pour m'instruire.

Ca sert à lancer l'interpréteur de commandes de Windows (tu sais bien, les anciennes commandes du Dos, que tu lançais en Basic avec SHELL "commande...").
Comme il n'y a plus de MsDos, il est émulé (quel beau mot !) dans Windows.

EXECUTE s'attend à trouver le chemin d'un programme exécutable, il ne sait pas exécuter directement les commandes Dos, il faut passer par l'interpréteur.

Quand tu lances Command.com sous Windows (touche Windows+"R"), tu te retrouves avec un écran type Dos où tu peux lancer les commandes.
Pour avoir la liste des commandes disponibles, tu tapes "help" après avoir lancé l'interpréteur.
Et pour avoir la syntaxe de chaque commande, tu tapes "help " suivi du nom de la commande.

Et "exit" pour sortir.

Ha oui OK!

Avec QB, je me servais de l'editeur QB, et pour être franc, je ne me suis jamais trop baladé dans le DOS, car j'ai peur de faire des conneries irréversibles sur mon système.

Pour ce qui est de EXECUTE, plusieurs choses:
Que le fonctionnement d'un programme appelé est passant ou non, ne vient pas de Panoramic, mais du programme en question. Je viens de faire plusieurs essai, ainsi Delphi se lance sans problème, alors que d'autre sont ignorés.
Il faudrait qu'il y ais une fonction qui permette de récupérer les paramètres d'un programme comme cela a été fait avec DLL.
Ensuite, il y a problème avec les espaces dans les noms, qui sont pour EXECUTE des passages de paramètre. Il faudrait que le fichier à appeler soit soit 'entre côte' ou même entre guillemet. Mais Jack veut que les commandes soient valable dans le temps. Pourquoi pas faire une commande comme RUN, avec ces nouvelles possibilités?. Par contre je ne vois pas comment passer des paramètres depuis un programme appelé. La seule possibilitée que je vois actuellement est de faire le passage par fichier interposé.
Ainsi, si je fais un programme en Delphi, j'enregistre les paramètres, et je récupère ceux-ci avec Panoramic. Cela peut se faire aussi avec un autre basic, on créé un fichier exe exécutable avec un basic qui le permet, on enregistre avec pour faire ce qui n'est pas encore prévu avec Panoramic, et on récupère le résultat avec Panoramic.
Sur ce, je retourne à mes obligations.
@+
NOTA:
Bienvenu à tous ceux qui nous rejoignent, mais comme je ne veux amplifier le compteur, qui va plus vite que moi, je laisse le soin aux autres à ma place.

Le problème n'est pas que le programme appelé se lance ou non, quand il ne se lance pas c'est que le chemin indiqué n'est pas correct (du point de vue de Execute). Ainsi s'il contient des espaces. Mais on peut contourner le problème en modifiant le chemin d'accès pour supprimer les espaces (version 'courte')
Le problème est qu'on ne sait pas quand le programme appelé se termine.
Et pour le passage de paramètres, le plus évident est le passage d'un fichier 'résultat', mais avec l'inconvénient dont je parle plus haut: on récupère la main alors que le fichier résultat n'est pas encore écrit.

Si le paramètre à passer est court et qu'on soit maître du programme appelé, un moyen serait de passer le résultat dans le Clipboard. Il suffirait alors de surveiller celui-ci dans l'appelant pour récupérer le paramètre. Malheureusement Panoramic ne permet pas de le récupérer de façon simple (dans une variable par exemple).

En attendant de trouver mieux.
Arréter le programme principal par < message > après EXECUTE pour reprendre la main soi-même.

Un peu comme le message

< votre page de test s'est-elle bien imprimée >
@+

C'est une idée, mais inapplicable dans certains cas: par exemple je fais une boucle contenant un EXECUTE d'une commande, toujours la même, je ne peux pas demander à l'utilisateur (moi-même, en l'occurence ) de rester là à confirmer à chaque tour de boucle.

Il faut JACK fasse quelque chose ici. Il va surement être nécessaire pour nous de faire nos propres commandes, en attendant qu'il avance dans le logiciel, et vu la demande, cela prendra beaucoup de temps. Il faut qu'il fasse déjà une instruction genre RUN ou CALL, avec la possibilité de mettre un nom de fichier avec des espaces (La majorité des programmes est installé dans 'Program Files' qui contient un espace. Déjà là il y a problème. Ensuite des programmes pourraient fonctionner et qui ne peuvent pas actuellement. Avec Justbasic, la compilation est TKN en extension, et execute n'accepte que EXE, et ignore le reste. Je pense que tous ensemble disions ce qu'il faut, pour qu'une instruction soit complète. Je pense en avoir dit pas mal. Cette instruction jusqu'à présent, je ne l'utilisais pas. Mais j'apprends à programmer en Delphi, pour pouvoir avoir les commandes qui me manquent, et là cette instruction devient indispensable.
Avez-vous d'autres idées, et quelqu'un autre que moi, peut-il en faire la synthèse (j'ai pour habitude de ne pas être suivi).
A vous

Mais si cosmos, moi c'est un peu pareil, je fais assez souvent appel à des programmes externes (que j'ai éventuellement écrit moi-même dans un autre langage) quand je ne trouve pas ce que je veux en Panoramic (ne serait-ce que les commandes comme DIR, SORT, COPY etc.), programmes que j'utilisais sans problème en QBasic (avec SHELL), et là je suis un peu frustré.

D'un autre côté j'ai quelques scrupules à accabler Jack de demandes quand je vois les listes faramineuses des autres (regarde un peu les 187 commandes de Nicolas !!!)... alors j'attends que ça se calme un peu. Et j'essaie de trouver des palliatifs, mais des fois ce n'est pas évident.

Je suis d'accord avec toi, Cosmos70, pour ce qui est des espaces dans la chaîne de caractère qui suit un execute.
Par exemple, pour le boulot, je me suis fait un moteur de recherche qui lance word ou excel en même temps que le programme recherché. Eh bien j'ai dû supprimer les espaces de tous les titres et les remplacer par des tirets, et mettre des tirets à la place des espaces pour tous les nouveaux fichiers que je crée, car si on fait :
execute "winword.exe Fiche de poste.doc"
ça marche pas du tout et ça se perd dans la recherche de 3 fichiers qui n'existent pas. Alors, il faut faire :
execute "winword.exe Fiche-de-poste.doc"
(en vérité, dans mon programme, ça marche avec des variables...)
Heureusement que c'est moi qui crée les fichiers, parce que si je devais utiliser des fichiers créés par d'autres personnes, jamais ils ne penseraient à ne mettre que des traits d'union.
C'est vrai qu'il faudrait utiliser des signes du style :
execute "winword.exe 'Fiche de poste.doc'"
ce serait beaucoup plus pratique.

Je comprends ta réticence de réclamer à Jack cette demandes. Mais vois-tu, je pense que c'est pour son bien. Si on peut faire soi-même ses propres commandes, nous même qui sommes conscient du travail à accomplir de Jack, il aura tout intérêt à nous faire cela . J'ai fais plusieurs demandes, je sais que je ne suis pas près d'avoir satisfaction, et bien de cette façon, il est tranquille avec moi, et toi, et d'autres... Il ne restera plus que Nicolas pour faire sa réclame (Nicolas, je m'excuse, mais avec tout ce que tu demandes !!! ???)
Je crois que c'est au bénéfice de Jack, parce que moi, je n'ai plus envie de demander quelque chose que je n'obtiendrais pas au vu de ce que je vois.
Et franchement Jack a bien du mérite de nous supporter. On ne fait que de geindre!. Tout ce que je demande, c'est une instruction qui lui permette de faire son logiciel à son rythme , sans qu'on vienne l'accabler à tout bout de champ.
@+

Je reprends pour ce que je crois être une bonne idée. C'est d'avoir un fichier de contrôle qu'on appellera ici "toto". Au départ Panoramique le détruit si il est présent.
On met Panoramic dans un boucle repeat : until files_exists("toto")=1
on a la commande execute pour le programme extérieur.
Ce programme fait son travail. Lorsque cela est fait, celui-ci créé le fichier toto (dans lequel d'ailleurs il peut passer des paramètres).
Lorsque Panoramic va détecter "toto", il continu, si des paramètres sont à prendrent, il les prend
Panoramic peut aussi passer des paramètres à travers un fichier, pour l'autre programme Je ne crois pas que ça résouts tous les problèmes (en dehors des espaces sur les fichiers). Vous qui avez déjà fait des programmes et être servi d'EXECUTE, je pense que vous pouvez dire si cela marche ou pas. Ce problème il faudra que je regarde plus tard. A faire 36 choses à la fois, je n'avance pas.
Pour ce qui est de passer des paramètres à travers clip bard, c'est une bonne idée, mais je ne sais pas si c'est toujours réalisable. Déjà je ne sais pas si avec MS-DOS, c'est faisable, ensuite on peut s'en servir dans le second logiciel. Que comprendra Panoramic avec les données du presse papier? Mais pour certain programme c'est effectivement une solution
Maintenant une question: est-ce qu'il y a une autre possibilité de passer des paramètres en dehors du presse papier ou des fichiers? Actuellement, je ne vois pas.
A+

Actuellement, je ne vois que les execute (execute "Pg-truc.exe 2 6 4")
ou les fichiers à lire (file_open_read 1,"F.txt", file_readln 1,n...).
Le presse-papier (ou clipboard pour les anglophiles), ça ne marche pas pour le moment (enfin, pas sous la forme de code).
Sinon, dans les choses qui n'existent pas non plus, mais qui peuvent constituer des idées pour Jack (quand il considèrera finalement sa todolist trop courte...!), c'est les poke et peek( ) que j'ai connu dans d'autres basic
poke sert à modifier un octet de la mémoire (on peut donc y stocker des infos en faisant plusieurs poke) et peek( ) à aller les rechercher ensuite avec un autre programme.
On pourrait aussi utiliser les dll_call... à condition de pouvoir créer des dll (ce que je ne sais pas faire).
On pourrait aussi utiliser parallel_out et parallel_inp( ) en branchant une mémoire sur la prise parallèle ou série (ce que je ne sais pas faire non plus). Mais peut-être cela peut donner des idées à d'autres qui en sauront plus sur la question...

Les peek et les poke, une vieille histoire. J'ne ai jamais parlé, par ce qu'aujourd'hui, je ne suis pas sur qu'on puisse se retrouver dans Windows. Pour ma part je ne connais pas une zone où on puisse se servir nous même sans conséquence. Il y a les adresses que l'on voit sur les interruptions, en dehors de ça; qui Y a t'il?. Moi je possède pas de documentation De plus je suppose que comme Atari, il y a des parties de l'ordi, où il faut passer en mode superviseur pour y avoir accès. Sur le forum, il y a certainement des gens beaucoup plus compétent que moi, pour fournir des explications.

Pour le passage de paramètres en retour, à mon avis il n'y a pas 36 solutions:
- le passage de paramètres au programme externe est déjà prévu dans EXECUTE, le problème c'est le chemin du programme externe qui peut comporter des espaces, et là ça ne marche pas (C:\Program Files\...), et il serait bon que ça marche, inutile de prévoir autre chose.
- la récupération de paramètres en retour, c'est par un fichier dont le nom peut être donné dans les paramètres 'aller', ou dans le presse-papier, à condition qu'on puisse récupérer celui-ci dans une variable, ça doit être faisable assez facilement par Jack (lecture/écriture dans le pp avec une variable, ou dans un fichier donné).

Problème du fichier: comme j'ai dit plus haut (ou ailleurs), l'appel au programme appelé étant passant, on récupère la main tout de suite, et le fichier résultat n'est pas encore créé. Et même le test File_Exists répond oui de façon erronée, alors on ne sait pas sur quel pied danser.

La nuit portant conseil, j'ai imaginé un système pour convertir les noms longs de chemins Windows (comportant éventuellement des espaces).
Par exemple pour convertir ceci:
C:\Program Files\Panoramic Editor V 0.9.15\PANORAMIC_EDITOR.exe
en ceci:
C:\PROGRA~1\PANORA~1.15\PANORA~1.EXE

Je n'arrivais pas avec EXECUTE à faire exécuter la commande DIR avec des espaces dans le nom. Alors je crée de toutes pièces un programme batch (.BAT) que je lance avec EXECUTE, et là ça marche, et je ne suis pas mécontent de moi.
Un inconvénient, c'est que ça affiche brièvement une fenêtre d'exécution à chaque appel du programme batch.
Si ça vous amuse, vous pouvez essayer (le Wait 100, toujours le même problème, devra peut-être être allongé dans certains cas...):

Code:

' NomCourt.bas conversion path long en path court
DIM r$, fm$, fb$, rr$, ra$, rp$, rs$, a$, i, j, k, nc$, lf
LABEL db

r$ = "C:\Program Files\Panoramic Editor V 0.9.15\PANORAMIC_EDITOR.exe"
fm$ = "C:\Temp\dir.tmp"
fb$ = "C:\Temp\Dirbat.bat"

print r$
lf = 1: File_Open_Write lf, fb$
File_Writeln lf, "@echo off"
File_Writeln lf, "DIR %1 /X >%2"
File_Close lf
rr$ = "": rs$ = r$

db:
FOR i = LEN(r$) TO 1 STEP -1
    IF MID$(r$, i, 1) = "\" THEN EXIT_FOR
NEXT i
IF i > 1
    ra$ = mid$(r$, i+1, len(r$)-i)
    r$ = left$(r$, i-1)
    rp$ = r$: if len(rp$) = 2 then rp$ = rp$ + "\"
    ' EXECUTE "Command.com /c DIR " + chr$(34) + rp$ + chr$(34) + " /X >" + fm$
    EXECUTE fb$ + " " + chr$(34) + rp$ + chr$(34) + " " + fm$
    Wait 100
    lf = 1: File_Open_Read lf, fm$
    While File_Eof(lf) = 0
        File_Readln lf, a$
        if a$ <> "" and left$(a$, 1) <> " "
            if upper$(mid$(a$, 50, len(a$)-49)) = upper$(ra$)
                nc$ = rtrim$(mid$(a$, 37, 12))
                if nc$ <> "" then ra$ = nc$: exit_while
            end_if
        end_if
    End_While
    File_Close lf
    if rr$ = ""
        rr$ = ra$
    else
        rr$ = ra$ + "\" + rr$
    end_if
    goto db
else
    rr$ = rp$ + rr$
END_IF
File_Delete fm$: File_Delete fb$
' Résultat dans rr$
Print rr$
end

Pour info: la commande DIR avec le paramètre /X affiche les noms de fichiers ou de répertoires avec leur version 'courte' si elle existe.

Je vois à l'instant ton message, mais je dois partir d'ici 5 mn.
Toi qui a déjà travaillé avec EXECUTE, peux-tu me dire ce que tu en pense de l'idée de faire une boucle d'attente avec repeat - until l'existence du fichier par l'autre programme. Ça m'énerve de ne pas avoir le temps d'essayer mes idées, je ne peux rien contrôler.
Au lieu d'un wait, ça ne marche pas la boucle pour savoir si le fichier est créé par l'autre programme?.
M... ça sonne, il faut que je quitte.
@+

Ton idée est évidemment la plus logique, et je l'ai déjà essayée, depuis longtemps:

Code:

EXECUTE "Programme.exe... " : ' avec résultat dans f$
WHILE FILE_EXISTS (f$) = 0: END_WHILE
FILE_OPEN_READ n, f$ ....

et là on part en erreur: fichier n'existe pas.

La grosse anomalie est que le File_Exists trouve le fichier avant qu'il ne soit effectivement écrit sur le disque. Il est écrit de manière logique, mais pas physique, et Windows doit répondre positivement au File_Exists, alors qu'il est encore trop tôt pour l'ouvrir, il est quelque part dans les limbes de Windows.

J'avais signalé cet inconvénient à Jack il y a très longtemps mais... c'est aussi parti dans les limbes.
La seule solution viable ce serait que Panoramic ait le moyen d'attendre systématiquement la fin d'exécution du programme appelé. Comme ça se faisait en QBasic à ce que je crois (enfin, tout se passait comme si...).

Je ne suis pas méchant, mais réaliste. Si tout est fait pour pas que ça marche, si on ne peut par interagir sur le programme avec un logiciel extérieur, si on peut pas avoir de contrôle, désolé pour Jack et vous autres, je crois que je vais finir par quitter Panoramic. J'ai besoin d'avancer, et non pas de piétiner, c'est pas du tout mon genre. Jamais!. J'espère que Jack fera quelque chose, à mon grand désarroi, moi il me faudra une solution.
Je n'ai pas d'ordre à donner à personne, Panoramic est gratuit, Les membres sont actifs, il n'y a que des bons points, sauf là, où je voudrais un déblocage.
Désolé Jack, vivement Noêl pour toi, et moi, je commence à avoir faim.
Je sais que je vais avoir la foudre du forum. Tant pis. Ce qui m'énerve est d'être défaitiste, alors que je me bâts pour le contraire.
Je vais prendre un peu de recul avec ce forum, le temps de voir comment ça va évoluer. N'oubliez surtout pas, que je me suis traité de "pauvre con, et tout le tintouin"par avance, et cela me donne le droit de le devenir!. Donc cela étant dis, je vais travailler pour moi.
Bonsoir à tous. Travaillez bien!

Citation :

je crois que je vais finir par quitter Panoramic.

C'est bien dommage.
Comme il y a plusieurs semaines, j'ai sorti un PLAY_WAIT sur demande de ce forum pour que l'exécution d'un programme soit suspendue jusqu'à la fin de la musique ou du film joué, je suis sur le point de sortir un EXECUTE_WAIT qui attendra la fin du logiciel exécuté.

Mais sortir une nouvelle commande demande beaucoup de temps et d'energie:
- il faut réfléchir à la manière dont on va faire, et la plupart du temps il faut aller chercher l'information et décortiquer beaucoup d'exemples écrits plus ou moins correctement en C++, en Java, en C#, en Perl, en Python ou parfois en assembleur,
- puis coder la commande dans PANORAMIC,
- la tester sur plusieurs exemples,
- faire des modifications de code selon le résultat des tests,
- écrire une fiche dans le manuel de référence (en anglais et en français),
- écrire quelques lignes dans le guide opérateur (là aussi en anglais et en français),
- intégrer la version de PANORAMIC dans l'EDITEUR,
- mettre cette version à disposition sur un serveur,
- écrire une annonce sur ce forum.

Je ne peux matériellement pas faire cela tous les jours.

Mais le développement de PANORAMIC continuera tel un rouleau compresseur, à son rythme propre, avec ou sans notre cosmos70.

Personne ici ne met en doute le boulot monstre que représente l'évolution de Panoramic, sans compter l'analyse des interventions du forum, en plus de tout ce qui est en attente.

Quoiqu'il en soit, l'annonce d'un EXECUTE_WAIT est une excellente nouvelle, et je suis sûr que ça va rassurer un peu l'impatient cosmos. Ce serait bien dommage qu'il nous quitte, ses interventions sont souvent constructives.

Merci Jack

Citation :

le développement de PANORAMIC continuera tel un rouleau compresseur

J'aime ton dynamisme batailleur !
Allez, tous avec moi :
Viiiiive Jack !!!

Je suis heureux de pouvoir te répondre. Vois-tu je n'ai aucune envie de quitter Panoramic.
Le problème est que tu nous laisses dans l'ignorance. D'accord avec toi, pour savoir que c'est énormément de travail que de faire ce que tu fais.
Voila pourquoi je suis venu à Panoramic. D'abord, il y a un bout de temps que j'avais télécharger ce logiciel, mais lorsque j'ai vu que tout était limité: objets les dim etc., je me suis dis qu'est-ce que je peux faire avec?. Et je l'ai laissé.
J'ai voulu me mettre à Python, et je suis rendu compte, que celui-ci demandait beaucoup de ressources, et que moi qui avait acheté un EEEPC, je me suis rendu compte que ce langage était lent, et d'après ce j'ai pu voir, il fallait des ancienne version de Python pour compiler.
Ruby, si il était possible sur une clé USB, est surtout fait pour Linux, et fonctionne mal sur Windows (pour ma part, je n'ai pu le faire fonctionner qu'en ligne de commande)
Après avoir essayé un tas de logiciel, pour savoir ce qui serait le mieux, a savoir: pouvoir le compiler, ne pas prendre trop de ressources, être transposable sur EEEPC, parce que la mémoire est limitée. Etre rapide en programmation, parce que moi, les idées fusent et j'aime bien les voir concrétiser, et je n'ai pas le temps des tas de lignes de code.
Il y a 3/4 ans, j'ai voulu apprendre le C avec Dev-C++, mais là si j'avais un bon tuto, je me suis vite rendu compte, que je n'aurais jamais assez de temps pour aller au bout, et que le développement d'un programme était trop long pour moi.
Au bout d'un moment, je me suis dis, je vais revoir ce programme: Panoramic. Après avoir fait quelque testes, j'allais abandonner parce que les limitations étaient trop basses, et miracle, voila que tu dis que tu mets à notre disposition pour le 15 aout je crois une version complète sans les restrictions, et j'ai continué. Voila enfin un langage, que je connais, donc pas trop de perte d'adaptation, qui se programme facilement, en plus et c'est des moindre, le développeur est français et disponible, et les résultats qu'on obtient si tout se passe bien est superbe.
Chemin faisant, voyant les possibilité de ce langage, et moi évoluant avec, je me rends compte, qu'il y a des choses à faire pour que tout soit pour le mieux. C'est du basic, et un logiciel en basic a ses limites en développement (je le sais), mais le problème est qu'on ne sait pas ce que tu fais.
Sur ce forum, il n'y a pas seulement des solutions qu'on apporte, mais il y a aussi des questions, dont on a pas de réponses.
Je me suis dis: je vais faire mais propres commandes avec un autre langage, et de ce faites, j'étais en train d'apprendre le pascal pour créer ces commandes, et dans ma tête, j'avais le schéma pour me servir de ces commandes.
Depuis quelques temps, je vois des problèmes avec EXECUTE, avec l'intervention de Jean Claude, de JL35, pour certain problème avec cette instruction.
Fort des réponses cet après-midi, de JL35, j'ai compris que tout tombe à l'eau. Les améliorations demandées, il n'en as jamais vus le jour, et là il faut que tu changes certaines choses.
D'abord, il n'est pas indispensable d'intervenir à chaque question. Mais le mieux serait de prendre note, et disons tous les 15 jours, mais là c'es toi qui voit, tu fais la synthèse de ce que tu as retenu
Ensuite il serait bien que tu dises ce qui est en court et une idée du temps très approximatif qu'il faudra pour la sortie des instructions (je ne suis si idiot que je le dis, je sais que le travail et la famille interfaire dans cette durée, et parfois aussi des imprévus)
On aimerait bien (moi en particulier) connaitre les parties de ta liste qui sont dans tes projets.
Lorsque qu'on fais une demande, savoir si tu la prends en considération ou non, mais pas "hop dans to-list", mais si ça demande 1 mois, 2 mois, 6 mois, une année, ou plus.
Pour ma part, j'avais demandé si on pouvait avoir une variable système pour le numéro de ligne, je pense que c'est aux oubliettes, alors que j'avais l'impression que c'était proche.
Je n'ai pas de réponse concernant la rotation d'une image, donc on oublie
Je n'ai pas de réponse concernant stretch_on et les barres de défilement, donc on oublie.
Il y a plein de petites choses dont on ne sais rien.
Là tu viens de dire que tu prévois de sortir EXECUTE_WAIT, c'est très bien, si tu l'avais dit avant, tout ce tintouin aurait été inutile.
Maintenant je sais que je pourrais avancer. Si j'étais resté silencieux, cet après-midi, on aurait pas eu cette information, et moi j'aurais compris que ce dont je prévoyait tombait à l'eau.
Comme tu vois, c'est pas très difficile, tous les 15 jours / 1 mois, fais un récapitulatif de nos demandes, et tient nous au courant de ce qui sortira dans les mois à venir.
J'ai visité d'autre forum, squeak, scratch delphi pascal Mxbasic RapidQ, et plein d'autre, je ne retrouve pas la même interactivité qu'ici. Il y en a qui laisse les questions sans réponses, j'ai même vu des commentaires du genre "pourquoi tu as pas dit ..., et la réponse: je ne vais quant-même pas leur mâcher le travail", entre les réponses sms, les phrases avec 4 5 smileys par phrase, etc... .Sois sympa, fais en sorte qu'on est envie de rester sur ce forum, et te porter en triomphe.
Bonne nuit

C'est encore moi, et j'en rajoute une couche. Pour quelqu'un qui veut se taire!!!
Nous connaissons les problèmes de Windows, dont les secrets sont difficilement accessibles aux européens, il n'y a qu'à voir les amendes encourus contre Windows. Pourquoi lorsque tu as des difficultés à avoir des renseignements au sujet de tel ou tel demande, tu ne nous en ferait pas part. Personne dans ce monde, quelque soit ses compétences, ne peut tout savoir. Lorsqu'on va voir un médecin, celui-ci vous renvoi, ou demande conseil à un spécialiste. Certaines personnes sur ce forum ont peut-être la compétence pour répondre à un problème, et t'aider dans ta tâche. Il est évident qu'il devra fournir ses sources, pour être sure qu'il n'y ai pas de droits à respecter. Les gens ne demandent qu'à t'aider, et même si tu voudrais que ton travail soit personnel, il n'y a pas de honte à utiliser le service des autres. Que les renseignements que tu recherches, viennent de Google, de documents, d'amis, ou du forum, qu'est que cela change. En mettant tout le monde à contribution, d'abord tu fidélises tes membres, tu avances plus vite si on t'apporte un solution ou un renseignement vital, et ensuite on comprends le pourquoi de ce qui n'avance pas.
Courage A+

Citation :

le développement de PANORAMIC continuera tel un rouleau compresseur

Je recite à nouveau cette phrase, qui, me semble t-il, est importante.

Dans la société ou je bosse, nous avons souvent les mêmes impatiences vis à vis des analystes dévelloppeurs de la boite. Nous focalisons sur un problème particulier, mais eux ils travaillent sur le long terme, donc ils prennent nos demandes en considération, mais ils dévelloppent suivant leur cahier des charges.
Pour PANORAMIC c'est pareil. C'est mon opinion, elle n'engage que moi.
Je suis d'accord, ce serait bien de voir ou l'on va. Jack, lui il sait ou il va.
Peut-être un peu plus d'infos dans ce qui est en cours, serait la bienvenue, mais c'est encore du travail supplémentaire pour Jack. Il n'a comme nous que 2 bras, il faut être patient.
A+