Programmer avec le composant de I.E. 6
cs_NoFutur
Messages postés
171
Date d'inscription
mardi 17 décembre 2002
Statut
Membre
Dernière intervention
6 mai 2007
-
4 nov. 2005 à 14:10
mythic_kruger Messages postés 241 Date d'inscription jeudi 8 janvier 2004 Statut Membre Dernière intervention 10 novembre 2005 - 10 nov. 2005 à 06:08
mythic_kruger Messages postés 241 Date d'inscription jeudi 8 janvier 2004 Statut Membre Dernière intervention 10 novembre 2005 - 10 nov. 2005 à 06:08
A voir également:
- D é p a n n a g e s e r r u r i e r v o i t u r e e u r 5 0 0 % 0 % m o y e n 6 6 0
- Créer site e lerning - Forum PHP
- Base de donnée e commerce - Forum SQL
- Awt-eventqueue-0 - Forum Java
- 0++ - Forum C / C++ / C++.NET
- Erreur e/s 32 ✓ - Forum Delphi / Pascal
1 réponse
mythic_kruger
Messages postés
241
Date d'inscription
jeudi 8 janvier 2004
Statut
Membre
Dernière intervention
10 novembre 2005
10 nov. 2005 à 06:08
10 nov. 2005 à 06:08
La question est bien posée. En effet, micro$oft rend obsolète ses propres produits dans sa logique de fric sans limite. VB? VB est du passé voyons, aujourd'hui on programme en DOT NET. "Visual Fred" comme le nomment les programmeurs les plus luicides, par une ironie qui dérange les faiseurs de fric sur le dos des utilisateurs.
L'environnement évolue. C'est une certitude, le composant cité ne SERA plus fonctionnel dans quelques années. Cependant il faut profiter de la vie. De sa durée de vie à lui. Un conseil personnel, laisser tomber les langages de haut niveau et se maintenir aux langages de bas niveau comme le C ou l' assembleur, car eux dépendent de facteurs bien plus indépendants de microsoft.
Le temps a prouvé que le plus grand détracteur des composants microsoft n' est paradoxalement pas celui des composants de la concurrence.
En outre, qu'est-ce qui garantit que chaque contrôle n'est pas équipé d'une routine interne qui se connecte chez microsoft? Parano? Riez.
Pourtant le contrôle que vous évoquez est extraordinairement avancé, évolué. Difficile de s'en passer, sinon de programmer sur son équivalent open source (qui ne coute pas plus cher que de respirer).
Ceci dit, il est possible de développer sur un contrôle nommé, puis de correler l' évolution de l' application à celle du contrôle -par là même forcer l'utilisateur final à upgrader régulièrement- comme un soldat qui obéit sans réfléchir.
L'environnement évolue. C'est une certitude, le composant cité ne SERA plus fonctionnel dans quelques années. Cependant il faut profiter de la vie. De sa durée de vie à lui. Un conseil personnel, laisser tomber les langages de haut niveau et se maintenir aux langages de bas niveau comme le C ou l' assembleur, car eux dépendent de facteurs bien plus indépendants de microsoft.
Le temps a prouvé que le plus grand détracteur des composants microsoft n' est paradoxalement pas celui des composants de la concurrence.
En outre, qu'est-ce qui garantit que chaque contrôle n'est pas équipé d'une routine interne qui se connecte chez microsoft? Parano? Riez.
Pourtant le contrôle que vous évoquez est extraordinairement avancé, évolué. Difficile de s'en passer, sinon de programmer sur son équivalent open source (qui ne coute pas plus cher que de respirer).
Ceci dit, il est possible de développer sur un contrôle nommé, puis de correler l' évolution de l' application à celle du contrôle -par là même forcer l'utilisateur final à upgrader régulièrement- comme un soldat qui obéit sans réfléchir.
