TIMER VS SETTIMER

Question

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 !!!

cs_Exploreur · Answer

Salut,

Tout dépend aussi de la précision que tu souhaites...

A+
Exploreur

 Linux a un noyau, Windows un pépin

youil · Answer

En faites je voudrais avoir quel sont les avantages et les désavantages de l'api settimer.Pour comparer avec le timer .net 2005.

jmfmarques · Answer

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 !

cs_Exploreur · Answer

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

youil · Answer

Oui, sais pour ça que je veux s'avoir les différences entre les 2 pour voir quelle est le mieux.

jmfmarques · Answer

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.

cs_Willi · Answer

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 :)

cs_casy · Answer

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 #

cs_Willi · Answer

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 :)

Utilisateur anonyme · Answer

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

Neo.balastik · Answer

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

cs_casy · Answer

"...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 #

TIMER VS SETTIMER

12 réponses

Votre réponse

Discussions similaires