youil
Messages postés67Date d'inscriptionvendredi 28 mars 2003StatutMembreDernière intervention12 juillet 2011
-
24 mai 2007 à 19:59
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 2014
-
26 mai 2007 à 09:06
Je voudrais avoir qu’elle est le mieux entre les 2, le contrôle timer .net 2005 ou l'api settimer.
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 24 mai 2007 à 20:09
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 !
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 24 mai 2007 à 20:37
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_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 24 mai 2007 à 21:25
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 #
Neo.balastik
Messages postés796Date d'inscriptionjeudi 17 mai 2001StatutMembreDernière intervention 5 mai 20097 25 mai 2007 à 13:08
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 ?
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 26 mai 2007 à 09:06
"...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 #