Discussion :

[Jlmat]

Bonjour,

Je vous propose un nouvel élément à utiliser : Compteur Digital et Actions utilisateur

Écrit en Lazarus 3.6, testé sur Windows. Ne devrait pas poser de problème pour l'adapter en Free Pascal ou Delphi.



C'est un compteur Digital avec ses fonctions classiques permettant d'interrompre le comptage précis à tout moment, de le reprendre ou de le réinitialiser.
1. Affichage digital d'un compteur avec des images pour les digits.
2. Un comptage du temps de rafraichissement de l'affichage est précis et utilise l'horloge interne.
3. Les commandes start, Pause et Stop sont basées sur une gestion des interruptions du compteur : La solution choisie est Application.ProcessMessages dans la boucle de temporisation pour permettre à l'application de rester réactive.

Qu'en pensez-vous ?

[Roland Chastain]

Bonjour !

Merci pour le partage.

Dommage que ce soit pour Windows seulement. Du coup je ne peux pas l'essayer.

Le programme qui s'exécute dans la procédure liée au clic du bouton, d'accord ça fonctionne, mais bon... L'exemple serait plus intéressant (à mon humble avis, et si je peux me permettre) avec un thread, comme vous l'indiquez vous-même en commentaire. En plus, ce n'est pas difficile à faire.

Il y a une unité dans le ZIP qui ne fait pas partie du projet.

[Roland Chastain]

Voici une version multiplateforme vite faite, utilisant GetTickCount64.

[Jlmat]

Merci Roland pour ta proposition de rectification du code pour que ce soit multiplateforme.

J'avoue que je ne sais comment faire cela! Si je regarde Le Wiki ICI, j'avoue que ça n'est pas très clair. Il serait peut-être utile de prévoir lorsque l'on fait un nouveau projet ou code, que Lazarus mette à notre disposition un menu avec l'option "Application Multiplateforme". Je n'ai pas encore installé Ubuntu.

Je vais proposer une version avec thread dès que j'aurai un moment...

[Roland Chastain]

Pas de quoi.

Il n'y a rien de particulier à faire pour qu'une application Lazarus soit multiplatforme. Il suffit de ne pas utiliser l'unité Windows !

Nous attendons avec impatience la version avec thread !

[Jlmat]

Bonjour,

J'ai réussi à créer le compteur avec le thread, mais j'ai encore des soucis dans la cohabitation des deux méthodes : Process Message et Thread, les deux ont leur raison d'être et peuvent effectivement être dans une même application, sauf qu'effectivement dans mon cas, je cherche à basculer de l'une ou l'autre méthode par un choix par Radio Button pour la gestion d'un même afficheur, ce qui est sans doute un cas limite. Là je suis un peu occupé, mais je devrais pouvoir résoudre le bug cette semaine.

A+

[Roland Chastain]

Oui j'imagine que ça ne doit pas être simple de mettre les deux méthodes ensemble. Cohabitation est vraiment le mot juste.

Je ne sais pas si les autres seront d'accord mais pour ma part je n'aime pas utiliser Application.ProcessMessages. Ça peut dépanner mais c'est toujours le signe (me semble-t-il) que le programme n'est pas bien conçu.

Pourquoi ne pas conserver la première version du programme dans un dossier séparé ? Enfin, c'est ce que j'aurais fait. En tout cas j'ai hâte de voir la nouvelle version.

[Jlmat]

... pour ma part je n'aime pas utiliser Application.ProcessMessages. Ça peut dépanner mais c'est toujours le signe (me semble-t-il) que le programme n'est pas bien conçu.

Pourquoi ne pas conserver la première version du programme dans un dossier séparé ? Enfin, c'est ce que j'aurais fait. En tout cas j'ai hâte de voir la nouvelle version.

Bonsoir,

Oui, c'est le premier réflexe que j'ai eu de séparer les deux méthodes, c'était évidemment plus simple... Mais je trouve intéressant cette interaction qu'il y a entre les deux solutions, ça oblige à réfléchir sur le niveau de la couche logicielle. Bah je crois que je suis un peu fou d'aller sur ce niveau, j'ai autre chose à faire. Je pense que cela vient du fait que les mêmes fonctions et commandes sont les mêmes pour les deux processus... Ils n'aiment pas se passer la main l'un après l'autre après une pause... Je vais voir, je peux séparer les commandes, ça devrait résoudre le problème.

je n'aime pas utiliser Application.ProcessMessages

Bah, je suis de la vieille école où l'on était heureux d'avoir ce ProcessMessage. Sans doute, il est plus simple à mettre en place. J'ai toujours eu quelques difficultés avec le multithread, non pas pour un seul processus comme ce compteur, mais lorsque plusieurs tâches différentes sont en Jeu. Le code devient plus conséquent, mais je vais en avoir besoin je pense de m'y replonger. J'ai d'ailleurs un exemple pédagogique que j'avais fait à l'époque avec delphi 7...

Bon, je me posais la question comment on fait pour modifier un code déjà posté? En accédant à mon source, je ne vois pas d'option de modification ou mise à jour!
Sinon, je pourrais poster ma version Thread uniquement comme nouveau code. Je vais vous le soumettre ici en attendant dans une version épurée vite fait. Je n'ai pas enlevé le traçage qui m'aidait à débugger : ThreadCompteur.7z

A+

[Roland Chastain]

Merci pour la nouvelle version.

Bon, je me posais la question comment on fait pour modifier un code déjà posté?

Je ne sais pas si c'est possible. En revanche, je sais que vous pouvez ajouter la deuxième version.

La version thread fonctionne bien chez moi, mais j'ai quand même quelques critiques.

Normalement vous ne devriez pas modifier directement Form1 depuis TCompteurThread, comme ici par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
procedure TCompteurThread.StartCounter;
begin
  Form1.Memo1.Append('THR: StartCounter appelé et compteur repris');

À mon avis (mais je peux me tromper, et ça se discute), les méthodes StartCounter, PauseCounter et ResetCounter ne devraient pas faire partie de la classe TCompteurThread, et même elles ne devraient pas exister du tout.

Personnellement je créerais le thread pour commencer à compter, et je le terminerais et le libérerais en cas de pause. Avoir un thread actif pour ne rien faire, à quoi bon ? Mais bon, encore une fois, ce n'est que mon humble avis.

[Alcatîz]

Bonjour,

Bon, je me posais la question comment on fait pour modifier un code déjà posté? En accédant à mon source, je ne vois pas d'option de modification ou mise à jour!
Sinon, je pourrais poster ma version Thread uniquement comme nouveau code. Je vais vous le soumettre ici en attendant dans une version épurée vite fait.

J'ai édité la fiche de téléchargement pour proposer les deux versions.

[Andnotor]

Normalement vous ne devriez pas modifier directement Form1 depuis TCompteurThread, comme ici par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
procedure TCompteurThread.StartCounter;
begin
  Form1.Memo1.Append('THR: StartCounter appelé et compteur repris');

Ici en l'occurrence ça ne pose pas de problème puisque cette méthode est appelée depuis la tâche principale. Il ne faut pas confondre l'objet TThread, simple objet comme tous les autres, et sa méthode Execute qui est effectivement la tâche secondaire.
Ce sont les accès depuis Execute (ou les méthodes invoquées depuis cette dernière) qui doivent absolument être synchronisés d'une façon ou d'une autre.

À mon avis (mais je peux me tromper, et ça se discute), les méthodes StartCounter, PauseCounter et ResetCounter ne devraient pas faire partie de la classe TCompteurThread, et même elles ne devraient pas exister du tout.

Ca se discute en effet mais le faire ainsi rend le code beaucoup plus portable. Réutiliser cet objet dans une autre app se ferait sans se poser de question ; on appelle Start/Stop/Pause

Personnellement je créerais le thread pour commencer à compter, et je le terminerais et le libérerais en cas de pause. Avoir un thread actif pour ne rien faire, à quoi bon ?

Ca se discute une nouvelle fois.

Ici c'est la base de l'application et sans lui elle ne sert à rien, je l'aurais même créé une fois pour toute au lancement de l'app. Il en serait autrement (et encore) pour une tâche de mise à jour invoquée sporadiquement.

Ce qui ne va pas est la façon dont ce thread est "soi-disant" mis en pause ; dans les faits il ne l'est pas puisqu'il travaille toutes les 50 ms. Il faut remplacer cette logique par une véritable fonction d'attente telle que TEvent. Un thread correctement mis en attente ne consomme plus aucun temps CPU puisqu'il n'est plus planifié par l'OS. Pour reprendre ton terme : il existe mais n'est plus actif

[Jlmat]

Bonjour à tous,

:mouarf: Quelle horreur ce VIP sous notre Avatar! Enfin, c'est pour la bonne cause, plus petit ou discret aurait pas été plus mal...

1. Comme je l'ai dit à Roland, j'ai épuré mon code de test pour lui donner la version extraite rapidement de la solution Thread qui était encore en test dans un autre contexte de code.
Il est bien sûr évident que l'instruction "Form1.Memo1.Append..." n'était là que temporairement pour les tests qui étaient en cours.

2. Par contre effectivement, je développe des exemples que j'essaye de rendre portable au mieux de mes possibilités et je rejoint Andnotor sur le fait de développer une classe spécifique qu_e je transforme en une unité qui s'enrichira au fur et à mesure des besoins, avec par exemple plusieurs formats de sortie etc.
mais je rejoins aussi Roland lorsqu'il dit que l'on pourrait se passer des méthodes StartCounter, PauseCounter et ResetCounter. Je vais voir si je peux développer une autre version du Thread plus légère...

3. Finalement, j'avais pensé présenté les deux méthodes l'une à côté de l'autre tout en étant indépendantes. Dans certains cas, la méthode ProcessMessage est encore utile lorsque par exemple une propriété (ou un évènement) n'est pas disponible dans la version d'un contrôle, on peut toujours intercepter le message de l'application par les constantes de FCP, Winndows, RTL etc...

Bon, si je comprends vos messages, vous préférez que je publie la version Thread séparément?

A+

[Jlmat]

Bonsoir,

Je vous donne ici la version minimale du Thread pour le compteur. Je crois que c'était ce que Roland me demandait depuis le début : SimpleThreadCompteur.zip.

Je pense que je vais avoir besoin d'un Thread plus sophistiqué pour gérer d'éventuels conflits sur un même contrôle (en l'occurence ici, un compteur à affichage digital).
Par exemple, un compteur qui relèverait des anomalies en provenance de différents systèmes, chercherait à incrémenter le compteur en même temps et certaines demandes en provenance d'autres processus pourraient se fondre ou être perdus car le compteur est déjà sollicité et être en train de mettre à jour le compteur.

Je vais donc écrire et publier j'espère une version multithread dans des interactions diverses entre le simple Thread (donné ci-dessus) et un thread plus élaboré sous forme de classe transportable dans une unité dédiée. Je la mettrais sur ce forum pour me dire ce que vous en pensez avant de le publier.

A+

[Roland Chastain]

@Jlmat

Merci pour la nouvelle version. Je vais de ce pas l'essayer !

@Andnotor

Merci pour ta réponse très instructive.

[Roland Chastain]

La nouvelle version fonctionne parfaitement.

Sans vouloir négliger les remarques fort instructives d'Andnotor (que j'ai au contraire lues avec attention), je vous propose une version conçue de la façon que j'ai dite précédemment, ce qui permettra peut-être d'en voir les avantages et les inconvénients. L'avantage, c'est que j'ai pu supprimer bon nombre de variables et d'instructions !

[Jlmat]

... je vous propose une version conçue de la façon que j'ai dite précédemment, ce qui permettra peut-être d'en voir les avantages et les inconvénients. L'avantage, c'est que j'ai pu supprimer bon nombre de variables et d'instructions !

Ha oui, effectivement, c'est la version minimaliste de ma minimaliste. OK, et bien vous me donnez du travail supplémentaire, mais ça peut être utile. Je vais ajouter ta version à mes derniers tests d'un thread plus élaboré qui va contrôler les deux versions minimalistes en concurrence d'accès d'un compteur commun avec traçage si possible pour voir les différences.

A+

[Jlmat]

Bonjour à tous,

Je reviens après un temps d'absence pour faire suite aux discussions en cours. N'ayant pu mettre à temps des exemples progressifs sur l'utilisation des threads, je m'apprêtais à télécharger différents exemples, puis à la fin, le logiciel m'indique que mon dépôt n'est plus accessible parce qu'un responsable est en train de valider mon source, alors que j'étais en train de télécharger une capture d'écran de mon application.

Alcatiz, je ne pense pas que c'est toi! Je t'ai envoyé un message il y a quelques jours... L'as-tu vu?
S'il y a un temps limité pour rédiger les explications, il faudrait qu'on le sache. Car je n'ai fait aucune fausse manip alors, c'est dommage... Je n'ai pas eu le temps de charger la bonne capture d'écran de l'application avec Thread... On ne peut toujours pas modifier avant de faire valider, ça manque...
Peux-tu me dire si tu as une trace du dépôt que j'avais commencé à faire?

C'est quand même rageant d'être interrompu en plein chargement des explications, je vais être obligé de tout le processus d'explications et de présentation!

Bon en tout cas, pour les bonnes nouvelles, c'est que je travaille sur un composant très élaboré de Thread, c'est pour cette raison que j'ai mis longtemps avant de revenir vers des codes plus simples. Car pour l'instant je bute sur les différents temps internes au Thread qui donne des résultats totalement faux pour des impulsions très rapides en essayant de ne pas surcharger le CPU... Mais je voulais aborder ce sujet plus tard.

A+

[Jlmat]

Merci Jean-Luc

Le dernier source multiplateforme déposé est ici et comme tu le recommandes, j'ai récapitulé toutes les sources valides dans un seul Zip.
il y a un pdf qui accompagne les différentes sources et détaille en particulier le rôle des différentes parties du Thread.

Le Thread définit trois modes de comptage pour le rendre utile dans de nombreux cas. Il permet de l'utiliser en simple comptage automatique d'impulsions lentes ou rapides ou bien de compter des évènements en provenance de l'extérieur. Sur l'image ci-dessous, c'est le bouton "Pulse" qui simule ces impulsions externes. L'utilisateur pourra déterminer les paramètres via des propriétés publiques de la class. Tous les détails sont mises dans le PDF qui est joint à la source.



N'hésitez pas à me faire part de vos remarques, car j'ai deux autres sources en préparation: Un source pour une utilisation multithread et un autre plus complexe qui se voudrait universel!?!

A+