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]

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]

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]

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+

[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+