Commande EXECUTE

Salut Jean Claude
Ma volonté, n'est pas de donner du travail supplémentaire, mais au contraire par le forum de l'aider. En tout cas, je ne pense pas avoir dis le contraire sur mes interventions. Si on a une commande execute qui fonctionne bien, déjà quelques-uns d'entre-nous sommes capable de résoudre une partie de nos problèmes, et peut-être ceux des autres: cela laisse déjà plus de temps à Jack. Ensuite si Jack nous fait part des difficultés à trouver tel info, et que l'un d'entre nous trouve le moyen de le lui donner, ce serait une avancée pour Jack, non?.
Il pourrait faire un tableau de ce qu'il envisage de faire dans ces prochains mois, et mettre en face, le ou les renseignements qui lui manquent. En faisant une mise à jour de cette liste de temps en temps, on sait ce qu'il manque. Si tel renseignement manque, on comprend pourquoi celle instruction reste de côté. Windows est très compliqué, et ceux qui le conçoivent font le maximum pour camoufler leur code, et garder pour eux les infos qu'on a besoin pour avancer.
Est-ce que un moment ou un autre, je demande plus de travail à Jack? Non c'est tout le contraire, et je pense même qu'il devrait s'arrêter un peu pour ne pas être saturé.
Pour ma part, il y a 2 ou 3 choses que j'ai besoin pour faire se que j'ai prévu. Si c'est impossible d'avoir la possibilité de continuer, comment veux-tu que je ne cherche pas la solution d'une autre manière?. Cela me parait logique. La conception de Panoramic, tel que l'a imaginé Jack est formidable, c'est un mec qui n'est pas con, donc moi, je ne souhaite pas quitter Panoramic, mais j'ai besoin d'une solution. Je la cherche, et je la trouve là où c'est possible. C'est tout. Le seul problème est que je sais pas ce qui va venir, et de par ce fait ne sais pas si je dois persister ici, ou voir autre chose en attendant. Si j'ai besoin d'une commande dans un avenir proche, et qu'il faut attendre 2 ans pour qu'elle apparesse, moi ça ne me convient pas, et comme je suis franc et réaliste, je le dis. Mais j'en veux pas à Jack! Pourquoi donc?, il n'y est pour rien, il est physiquement incapable de résoudre les problèmes de chacun. Tout prend du temps, même celui que je prends ces jours-ci sur ce forum dans mes interventions, alors que le codage que j'étais en train de faire, reste de côté.
@+

Fournir à un client une liste d'actions à réaliser avec une date limite, et me démener dans tous les sens pour arriver à réaliser ces actions pour la date convenue, afin d'éviter de payer des pénalités, ressemble étrangement à ce que je fais au travail.
Et je ne voudrais pas que PANORAMIC ressemble à du travail jalonné.

Cependant, je peux donner une liste très approximative de ce qui est prévu avec un ordre de grandeur du temps de réalisation.
La voici.
Je viens de la faire sur un coin de table. Je la complèterai car j'ai sans doute oublié des choses, mais les grandes lignes y sont.

Ce qui est la priorité:
refaire fonctionner le CLICKED()
refaire fonctionner dans l'EDITEUR la lecture des options enregistrées
mettre les fiches DIR_REMOVE et RMDIR dans le manuel de référence


Ce qui est prévu d'ici deux semaines à un mois: (le codage est commencé)
EXECUTE_WAIT : lance un logiciel et attend la fin
TO_BACK : fait passer un FORM en arrière plan
TO_FRONT : fait passer un FORM au premier plan


Ce qui est prévu dans un ou deux mois: (ce qui est à coder est clairement défini mais le codage n'a pas commencé)
CLIPBOARD_COPY$ : recopie une variable string dans le presse-papier
CLIPBOARD_PASTE$ : récupère le texte du presse-papier dans une variable string
CLIPBOARD_PICTURE_COPY : recopie l'image d'un PICTURE dans le presse-papier
CLIPBOARD_PICTURE_PASTE : récupère l'image du presse-papier dans un PICTURE
OFF_CHANGED : ignore l'événement "change"
OFF_KEY_UP : ignore l'événement "key_up"
OFF_KEY_DOWN : ignore l'événement "key_up"
NUMBER_LINE : numéro de ligne du source en cours d'exécution
NUMBER_OBJECTS : nombre d'objets système utilisés
NUMBER_3D_OBJECTS : nombre d'objets 3D utilisés
NUMBER_SPRITES : nombre de sprites utilisés
ON_MOUSE_UP : traite l'événement "bouton de souris relaché"
ON_MOUSE_DOWN : traite l'événement "bouton de souris enfoncé"
MOUSE_UP_CODE : numéro du bouton de souris relaché
MOUSE_DOWN_CODE : numéro du bouton de souris enfoncé


Ce qui est prévu dans les 3 à 6 mois: (ce qui est à coder n'est pas défini, mais la documentation nécessaire a été constituée)
READ a,b : le READ multiple (comme DIM)
DIM b(a) : le DIM dynamique
LPRINT : l'impression sur imprimante d'une variable
LPRINT_OBJECT : l'impression sur imprimante d'un objet système (MEMO, PICTURE, FORM)
LPRINT_DIALOG : le choix de l'imprimante


Ce qui est prévu plus tard: (en recherche de documentation ou documentation en attente d'être étudiée)
FORM_3D : un FORM dédié à la 3D en utilisant un moteur 3D existant (Irrlicht semble convenir)
utilisation de l'USB
utilisation du joystick
utilisation de la liaison série
utilisation des bases de données
utilisation plus universelle des DLL
instruction INCLUDE pour inclure un fichier .bas
variables locales
passage de paramètres à un sous-programme

Génial, ce sera beau, quand on aura tout cela. !
Juste une question :
Les LPRINT_quelquechose (vu qu'ils sont placés avant l'utilisation de l'USB) est-ce qu'ils fonctionneront sur des imprimantes branchées en prises USB ? (parce que les imprimantes en prises parallèles, on n'en trouve plus...)

Au fait, le memo_rich qui avait été promis il y a environ 1 an, il n'est plus d'actualité ?

Bien sûr, puis qu'un LPRINT_quelquechose appelle un API de Windows.
Peu importe si l'imprimante est sur un port USB ou parallèle, c'est Windows qui se débrouille pour l'envoyer à l'imprimante.

Par gestion de l'USB, je pensais à un pilotage de bas niveau pour envoyer ou recevoir des données élémentaires (exemple : montage robotique sur l'USB)

J'ai oublié le MEMO_RICH dans la liste, ainsi que le SPIN, etc...

Je la remets à jour dès que possible!

Salut Jack

Citation :

DIM b(a) : le DIM dynamique
LPRINT : l'impression sur imprimante d'une variable
LPRINT_OBJECT : l'impression sur imprimante d'un objet système (MEMO, PICTURE, FORM)
LPRINT_DIALOG : le choix de l'imprimante

ça me fait particulièrement plaisirs de voir ceci.
c'est super
bravo et bon courage
@+

Cette liste de projets avec estimation des temps me paraît une très bonne chose, c'était nécessaire pour calmer un peu les esprits et voir à peu près où on va. Personnellement ça me satisfait pleinement, mes desiderata y figurent tous parmi les autres.
Il est bien évident que la priorité c'est de réparer les bugs, c'est à dire consolider l'existant, par rapport aux nouvelles commandes.

Merci Jack pour ces précsisions rassurantes.

Voilà qui nous rassure et je dois admettre que l'on retouve, dans les projets, beaucoup de demande des foromeurs.
Bon courage !

bonjour jack.

sa fait pas mal de boulot tout sa, en tous cas chapeau jack .
moi aussi sa fait longtemp que j'attend un timer,mais je sais que tu a beaucoup a faire donc je patiente je sais que sa viendra un jour.
en tous cas merci pour ses nouvelles versions que tu nous fournies.
vive panoramic ,bonne continuation jack.

Je suis l'auteur de la polémique sur ce poste.
Je te remercie pour ta réponse, et vois-tu il y en a déjà pour plusieurs mois, et ne sera pas nécessaire, à moins que tu changes l'ordre des choses d'ici là,de revenir dessus, on sait où on va. La seul question qui reste en suspend: qu'en est-il des espaces dans le nom des fichiers dans execute?. Pour ma part j'en sais assez pour continuer. Si il n'y a pas de problème avec cette commande, je serais sous silence pour un bout de temps, je pense. Si je dois faire un programme, je le mettrais à la racine du disque, il y a que ceux qui voudrons se servir des programmes installés qui pourront avoir des problèmes. La question que je me pose, est-ce que ça marcherait avec un raccourci? si oui, ce serait une solution pour les espaces
Merci beaucoup. Je dois quitter l'heure est largement dépasser.

Ce n'est pas une polémique, tu demandes des choses, on répond (ou pas).
Ne culpabilises pas, tu dialogues tout simplement, comme nous. Même si, parfois, tu as le ton un peu rude, c'est ta personnalité, c'est comme çà.
Au moins on sait ce tu penses. Ta franchise, nous a bien servie, on ne peut pas le nier.

@cosmos
En ce qui concerne les espaces dans les noms de chemins d'accès, j'ai donné une ébauche de palliatif avec mon sous-programme de la page précédente (conversion de nom long en nom court).
Ce n'est peut-être pas très élégant, mais en attendant mieux c'est mieux que rien, ça permet de ne pas être bloqué.

En attendant de trouver une solution plus élégante, si possible.
Il faudrait que j'étudie ça de plus près, la syntaxe n'est pas évidente avec les quotes (") à placer judicieusement.

moi je suis pas impatien dans le temps avec panoramic sa prendra le temps qu'il faut

mais davoir une idée 6mois et + pour le travail qui va se faire je trouve sa super

je pensai pas pour la première année davoir instruction INCLUDE pour inclure un fichier .bas

merci pour le bon travail pour panoramic est surtout bon courage pour les impatien

a+

Oui mais toi tu es jeune, tu as tout le temps d'attendre !
Mais moi je voudrais bien avoir le temps de tester toutes ces belles commandes juteuses avant de devenir complètement gâteux !
Comment ça c'est déjà fait ?

J'ai essayé l'EXECUTE avec des noms de répertoire avec espaces ou avec des noms longs (commande DIR), rien à faire, j'ai beau essayer de mettre les quotes un peu partout ça ne veut pas marcher.

Super, brovo Jack pour tous ces beaux projets !

@cosmos70:

Citation :

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.

Je ne pense pas: si on passe un nom de fichier qui comporte des espaces à un exécutable, tout se passe correctement.

J'ai créé un fichier texte, que j'ai appelé mon fichier.txt et lorque je le charge dans le Notepad, il n'y a aucun problème.

Code:

execute "notepad.exe c:/mon fichier.txt"

lance le notepad qui charge correctement mon fichier.txt qui pourtant contient un espace dans son nom.

Désolé Jack, pas d'accord, pour moi cosmos a raison.
Le problème n'est pas dans les paramètres mais dans le programme appelé.

Copie par exemple notepad.exe dans Program Files et essaie:

Code:

EXECUTE "C:\Program Files\notepad.exe"

C:\Program est considéré comme le programme à exécuter, et Files\... comme les paramètres.
Ca ne part même pas en erreur (exécutable non trouvé par exemple), ça reste figé (ça doit boucler quelque part).

La seule solution, à mon sens, serait de prévoir dans la commande de séparer l'exécutable des paramètres, du genre:
EXECUTE "Programme.exe","Paramètres"

Effectivement, s'il y a un blanc dans le nom du programme, ça ne fonctionne pas car la commande EXECUTE recherche le premier blanc en partant de la gauche pour séparer nom de programme et paramètres.

Et cela est gênant.

Sans changer la syntaxe existante (pas de guillements pour séparer le nom de programme et les paramètres), on pourrait imposer que le nom du programme se termine par .exe ou .com, ce qui n'est pas le cas aujourd'hui.

Mais on perdrait au change.
Aujourd'hui, la commande EXECUTE est souple:

Code:

execute "notepad"

fonctionne sans .exe
Et il est même possible de faire:

Code:

execute "c:/fichier.txt"

commande qui lance le notepad (bloc-note pour les français) puis qui lui fait charger fichier.txt dans le cas où on a associé (dans l'explorateur Windows) une extension txt au NotePad.

On perdrait alors toute cette souplesse...

Je vais faire une nouvelle commande pour laquelle il sera obligatoire de mettre un .exe ou un .com, mais qui acceptera des blancs dans le nom de l'exécutable, car elle ne recherchera plus un blanc mais une séquence .exe ou . com, ou bien sûr .eXE ou .ExE, etc, etc.

C'est bien joli que ça marche avec notepad, Jack, mais ce qui est surtout dommage, c'est que ça ne marche pas avec word ou excel ou d'autres qui permettent d'appeler des fichiers autrement plus professionnels que les txt.
execute "winword.exe c:\Mes documents\Mon fichier.doc"
execute "excel.exe c:\Mes documents\Mon tableur.xls"
ça ne marche pas !!!
Alors, que tu fasses une nouvelle commande, Jack, pas de problème, mais pas en la limitant uniquement à des .exe et des .com
Il faut que ça puisse marcher avec .doc .xls .txt .rtf .jpg .bmp... etc... !!!

jjn4, dans ton cas, est-ce que le chemin complet de winword.exe et excel.exe est connu de windows ? (je ne peux pas essayer, je n'ai ni l'un ni l'autre). Notepad est un composant de Windows qui en connaît le chemin, mais pas winword ni excel.

J'ai essayé avec EXECUTE "wordpad.exe", ça ne marche pas, le chemin est inconnu (c'est dans C:\Program Files\Windows NT\Accessories\wordpad.exe").
Je le recopie dans C:\Temp, par exemple, et je crée un fichier Z:\Mon fichier.txt

Code:

EXECUTE "C\Temp\wordpad.exe Z:\Mon fichier.txt"

ne marche pas, mais

Code:

EXECUTE "C:\Temp\wordpad.exe " + chr$(34) + "Z:\Mon fichier.txt" + chr$(34)

marche très bien.
C'est normal, il faut bien que le programme appelé puisse distinguer les paramètres les uns des autres, s'il y en a plusieurs.
D'ailleurs si tu exécutes le premier exemple en ligne de commande, ça ne marchera pas non plus, wordpad essaie de charger le fichier Z:\Mon et considère la suite (fichier.txt) comme un autre paramètre.
Actuellement, il faut donc que le chemin de l'exécutable soit connu (notepad.exe est connu, mais pas wordpad.exe), que ce nom d'exécutable ne comporte pas d'espaces, et que, s'il y a des espaces dans un des paramètres celui-ci soit encadré par des quotes.

@Jack
Je trouve que la nouvelle commande exigeant .exe ou .com est assez restrictive, il faudrait au moins pouvoir lancer tout ce qui est exécutable: .bat, .vbs etc. (même si on ne peut lancer un exécutable par un fichier de données associé).

Une solution plus universelle serait peut-être de considérer que le programme à exécuter est ce qui précède le premier espace après le point ".", ce qui suit éventuellement étant le(s) paramètre(s).

Ainsi, on impose un suffixe, ce qui n'est pas une contrainte pour un exécutable, mais tous les suffixes fonctionnent. Et ça ne change pas la syntaxe actuelle pour le programmeur.

Jl35, as-tu regardé le post "fréquence MIDI" de Nicolas

Dans son code il fait appel à un prog extérieur execute "sndvol32.exe"
Cà n'a pas l'air compliqué. A+

Citation :

Une solution plus universelle serait peut-être de considérer que le programme à exécuter est ce qui précède le premier espace après le point ".", ce qui suit éventuellement étant le(s) paramètre(s).

Cette proposition me parait convenir. Elle éviterait la création d'une nouvelle commande qui porterait certainement à confusion avec la commande existante, avec à chaque fois la question: laquelle des deux dois-je utiliser selon ce que je veux faire?.

Je crois que ce serait bien comme ça. Et ça n'empêcherait pas de lancer par exemple notepad avec seulement le nom du fichier.txt, comme disait jjn4.

Jean Claude, ce n'est pas compliqué du tout d'utiliser la commande EXECUTE et elle marche très bien, et je l'utilise fréquemment.
Le problème actuel c'est quand le nom du programme comporte un ou des espaces. Mais Jack est conscient du problème et va nous régler ça un jour ou l'autre, pas de souci.

Je n'avais pas compris ce problème d'espace. A+