TIMER VS SETTIMER

Signaler
Messages postés
67
Date d'inscription
vendredi 28 mars 2003
Statut
Membre
Dernière intervention
12 juillet 2011
-
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
-
Je voudrais avoir qu’elle est le mieux entre les 2, le contrôle timer .net 2005 ou l'api settimer.



Merci pour vos réponse !!!

12 réponses

Messages postés
4822
Date d'inscription
lundi 11 novembre 2002
Statut
Membre
Dernière intervention
15 novembre 2016
14
Salut,

Tout dépend aussi de la précision que tu souhaites...

A+
Exploreur

 Linux a un noyau, Windows un pépin

 
Messages postés
67
Date d'inscription
vendredi 28 mars 2003
Statut
Membre
Dernière intervention
12 juillet 2011

En faites je voudrais avoir quel sont les avantages et les désavantages de l'api settimer.Pour comparer avec le timer .net 2005.
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
27
Je serais assez enclin à te répondre ainsi :

Si, d'un côté, l'on vante les mérites d'un FrameWork (bien lourd à mon sens), mais que, de l'autre (côté), on vante l'utilisation de l'API de Windows plutôt que celle du FrameWork... on peut se poser beaucoup de questions quant à l'utilité réelle de ce poids-loud (le FrameWorl)...
Mais ce n'est que mon avis... celui d'un insensé, pardi !
Messages postés
4822
Date d'inscription
lundi 11 novembre 2002
Statut
Membre
Dernière intervention
15 novembre 2016
14
Salut,

D'aprés ce que je viens de lire sur le net, l'api Settimer et Killtimer, te permèttes de faire un timer sans utiliser un contrôle Timer justement...

A+
Exploreur

 Linux a un noyau, Windows un pépin

 
Messages postés
67
Date d'inscription
vendredi 28 mars 2003
Statut
Membre
Dernière intervention
12 juillet 2011

Oui, sais pour ça que je veux s'avoir les différences entre les 2 pour voir quelle est le mieux.
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
27
Ce n'est en général pas le contrôle Timer, qui est gourmand en ressources (presque rien) mais les instructions qu'il exécute ...
Et puisque tu le trimbales déjà de gré ou de force (ton framework) ... utilise-le donc sans états d'âme.
Messages postés
2375
Date d'inscription
jeudi 12 juillet 2001
Statut
Modérateur
Dernière intervention
15 décembre 2018
22
Je suis d'accord dans le cas présent utilise le composant Timer fournit dans l'assembly System.Form (oui il existe d'autre Timer dans le Framework).

Exploreur pas mal la singature mais je préfère le pépin que le noyau :)
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
41
Perso moi aussi le pépin, le noyau j'ai pas réussi à l'avaler encore.

our en revenir au Timer, il existe certe le controle Timer comme en VB6, mais aussi la classe Timer, de fonctionnement quasi similaire, elle a l'avantage de ne pas etre un controle et donc peut etre utiliser en dehors d'une form, contrairement au controle qui lui exisge une form pour etre posé

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
Messages postés
2375
Date d'inscription
jeudi 12 juillet 2001
Statut
Modérateur
Dernière intervention
15 décembre 2018
22
le controle Timer de la classe Form peut etre utilisé hors Windows Form mais il a été optimiser pour ce type d'application alors autant l'exploiter :)
Messages postés
3172
Date d'inscription
dimanche 15 février 2004
Statut
Membre
Dernière intervention
9 avril 2017
35
Salut,

Si tu veux pas poser de contrôle, tu peux utiliser la classe System.Threading.Timer
Mais à mon avis, tout celà reviens un peu au même non ?





__________
 Kenji
Messages postés
796
Date d'inscription
jeudi 17 mai 2001
Statut
Membre
Dernière intervention
5 mai 2009
7
Salut ;O)

N'oublions pas qu'un programme écrit en .NET est 'censé' être portable sur d'autres OS (Linux, MacOS) incluant un Framwork qui respecte la standardisation CLI (Common Language Infrastructure).  Le code IL (Intermediaire Language) d'un exécutable .NET n'est pas exclusif à Microsoft, mais bien standardisé.

Donc si l'on utilise directement l'API Win32 en.NET (ce qui n'est pas interdit), l'exécutable devient du coup inexploitable sur d'autres OS vu que l'API réalise des opérations de bas niveau en code natif, non managé par le CLR (Common Language Runtime), généralement écrite en langage C.

L'appel d'API concerne exclusivement l'OS sur lequel l'application a été développée (utilisation de Kernel32.dll, User32.dll, Gdi32.dll,...).

Il est vrai que dans le cadre d'une application VB6, l'API de Windows était souvent sollicitée pour deux principales raisons : obtenir de bonnes performances et contourner les limitations inhérentes à ce langage en terme de fonctionnalités.

Les classes présentent dans .NET devraient remplacer la majeure partie des API utilisées dans VB6.  
Mais il vrai que nous ne développons pas toujours dans l'objectif de rendre portable notre application surtout si l'on vient exclusivement du monde VB6 (et très souvent tout ce qui englobe Microsoft).

Ceci dit, si on ne développe que pour le monde Microsoft, pourquoi s'en priver ?

Guy

 
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
41
"...N'oublions pas qu'un programme écrit en .NET est 'censé' être portable sur d'autres OS ..."

D'ou sort-tu une telle information ??????

Ca n'a jamais été le but de Microsoft de faire du Framework, une plateforme portable. Il n'y a, d'ailleur à ma connaissance aucun projet de développement de la portabilité de leur part.

Le seul projet existant est le projet Mono concernant la portabilité du framework sous Linux, Il est encore loin d'etre complet et stable.
Mais surtout il est completement indépendant de microsoft qui ne le soutient ni le voie d'un très bon oeil.

Si la struture du Framework et les différents langages afférents sont standardisé c'est avant tout pour une question de brevets et de droit d'auteurs.
Et si portabilité il doit y avoir, dans l'esprit de Microsoft c'est avant tout que les applications des autres univers soit portable vers Microsoft.

Si portabilité du framework, il y aurait du avoir, Microsoft n'arais pas conservé dans le Framework, l'accès aux apis windows, aux objet COM, et de manière générale, n'aurait pas permis d'écrire du code non-managé. Hors le Framework ne fait pas tout, même s'il fait beaucoup de chose. Le recours aux apis et au code non-managé est encore indispensable dès que l'on attaque de gros projets ou des fonctions particulières.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #