Discussion :

[Invité]

Bonjour.

Après mes déboires avec Sleep (voir mon topic du 29/10/2013 : Démonstration garantie sans trucage) avec lequel le système dort apparemment trop profondément , je cherche une autre méthode pour attendre "un certain temps".

Le but est d'attendre 1s (a priori) au démarrage du programme pour que certains composants matériels soient correctement reconnus, il s'agit de détecter les périphériques HID type IOWarrior24 à l'aide du composant de R. Marquardt (pour ceux qui connaissent, événement "OnArrival" qui devra reconnaître dans sa routine les circuits de ce type, il peut aussi y avoir une souris et un clavier parmi les HID ...). Normalement, vu le caractère multitâche de Windows, on n'est pas sûr que ces choses se règlent en premier ...

Je définis donc un timer Chrono1 (il y en a un deuxième qui est destiné à servir à autre chose), Enabled avec une valeur de 1000 (ms), je lui associe une routine contenant seulement Chrono1.Enabled:=false (qui est censée l'arrêter au bout d'une seconde) et dans la routine qui est lancée "OnActivate" de la fiche principale (il n'y a d'ailleurs qu'une fiche) je mets l'instruction apparemment innocente :
Repeat until not (Chrono1.Enabled)
croyant que le multitâche n'empêchera pas l'interruption timer de se produire.

Bang ! Mon appli est réduite (à l'exécution) sur la barre des tâches et je ne peux plus l'arrêter que par la commande réinitialiser dans Delphi ou la prise des 3 doigts (gestionnaire de tâches) dans l'environnement Windows.

Le multitâche de Windows ne serait-il vrai que quand il peut embêter (je reste poli ! ) les développeurs ? Loi de Murphy ?

Que faire ? Evidemment une solution serait de déclencher cette même routine d'initialisation, au lieu du "On Activate", par ledit timer Chrono1 au bout d'une seconde, et de mettre le programme dans un état d'attente lors du démarrage avec des indicateurs appropriés qui seraient testés par les autres routines événementielles, mais cela ne m'explique pas pourquoi une instruction au fond anodine et sans problème apparent m'envoie dans le "Walhalla" ...

Merci d'avance ...

[exoseven]

cela est parfaitement logique, ta boucle empêche le traitement des messages et comme le timer ne fait qu'envoyer un message pour signaler son état tu es coincé...

en restant dans ton idée, il faut que tu insères un application.processmessages pour traiter la file des messages.

mais bon cette solution est quand même bien moche.

Si je comprends bien tu veux simplement empêcher que les utilisateurs ne manipulent ton programme avant que le timer ne l'autorise

Alors depuis l'IDE tu fixes la propriété enabled de ta fiche à false et tu la réactive dans le OnTimer

[Invité]

Merci de ton idée avec le 'Enabled' qui est très bonne.

Je dois quand même mettre ma routine d'initialisation principale dans l'événement Chrono1.

Il ne s'agit pas simplement d'empêcher les utilisateurs de manipuler ; cela créerait de toute manière un rejet car le programme testera si le IOWarrior a été correctement reconnu (en particulier s'il n'est pas débranché ! ) avant d'y accéder, en regardant s'il y a un "identificateur" valide.

En fait la fiche sera directement fermée dans la routine d'initialisation sans même initialiser "pour rien" d'autres composants si un problème a été détecté. Ce qui impose d'attendre un peu ....

Ceci dit, après le "Sleep", je trouve quand même qu'il y a beaucoup (trop) de manières de bloquer le fonctionnement de Windows.

Alberich

[Andnotor]

Ceci dit, après le "Sleep", je trouve quand même qu'il y a beaucoup (trop) de manières de bloquer le fonctionnement de Windows.

Sleep ne "bloque" pas Windows contrairement à un boucle repeat..until. Sleep ne fait que mettre TON processus en pause alors que repeat..until fait tourner un processeur à plein tube
Bien sûr les deux sont bloquants au niveau de ton application puisque tu ne lui laisses pas le temps de gérer les messages en attente (dans un cas il roupille, dans l'autre il est déjà au triple-galop mais... tourne en rond) et comme te le signale ExoSeven, le déclenchement d'un timer est notifié par le message WM_TIMER.

Maintenant, si ce périphérique a été installé (il y a un driver), tu dois le retrouver dans la base des registres sous HKLM\SYSTEM\CurrentControlSet\Enum. Il est alors possible d'énumérer les périphériques connectés par RawInput et d'en déduire sa présence.
Et pour autant que ce IOWarrior supports une (dé)connexion à chaud (USB), tu peux en être informé par WM_DEVICECHANGE en s'enregistrant à l'aide RegisterDeviceNotification ou depuis Vista simplement par RawInput en définissant RIDEV_DEVNOTIFY à l'appel de RegisterRawInputDevices. La notification arrivant alors par WM_INPUT_DEVICE_CHANGE.

Y'a du boulot, mais là tu auras vraiment quelque chose de propre utilisant un minimum de ressource et surtout fiable

ps: quand tu auras compris que les timers ne sont pas là pour "corriger" des erreurs de comportements de ton application, tu auras fait un grand bond en avant

[Invité]

Toutes ces fonctions, reconnaissance lors du branchement avec liste des périphériques déjà branchés avant début du programme, déconnexion, sont prises en compte au niveau du composant qui ne fait que créer une "interface" compatible Delphi avec USB.dll , avec propriétés, méthodes et événements. Mais comme toujours, lors d'événements, il faut attendre la fin de l'exécution de la routine déclenchée avant de lire les résultats ! L'instantanéité n'existe pas dans l'univers de l'informatique. Ce n'est pas une erreur, c'est une autre conception du problème ...

Il me semble que l'existence de ce composant VCL (signalée sur de nombreux sites ... y compris celui du fabricant du IOWarrior ! ) permet quand même de simplifier les choses de manière "ergonomique" par rapport à un accès direct à la base de registres et le traitement des messages Windows presque au niveau "système". On l'associe à un "projet JEDI" OpenSource dont je n'avais jamais entendu parler avant. Il existe également une dll de pilotage spécifique à la gamme IOWarrior mais qui apparemment ne gère pas entre autres la déconnexion (il faut alors traiter les erreurs d'accès au circuit), et qu'il faut "traîner" en plus de l'exe lors du portage de l'application sur une autre machine, alors que Delphi intègre les codes des composants VCL dans l'exe.

Comme déjà dit, je voulais COMPRENDRE "le pourquoi du comment", mais j'étais de toute manière décidé (comme annoncé dans mon premier post) à déclencher la lecture des résultats de la reconnaissance des périphériques HID à la fin de la période de Chrono1.

N'oublions pas que ces circuits sont avant tout conçus pour des bidouilleurs en électronique qui ne sont pas forcément des bidouilleurs système (je laisse ce qualificatif au développeur du composant logiciel) ! Ce qui explique aussi le succès d'un Arduino par exemple !

Salutations de la part d'Alberich !