Discussion :

[comme de bien entendu]

Bonjour,
Plus je fais de l'Excel, et plus je m'apercois que l'on peut faire multitudes de choses avec. Notamment on peut faire des applis à partir d'Excel sans même savoir que l'on est dans un tableur à la base.
On peut aussi faire de l'implémentation d'interface facon Java et manipuler des classes. Voir faire de l'héritage en copiant des classes.
D'où cette question : Qu'est ce que l'on ne peut pas faire avec Excel ? (avant que dise cela à la machine à café devant le directeur technique de la boîte. ;-)

[Daniel.C]

Bonjour,

Excel a des limites, par exemple, tu ne peux pas disposer de 257 colonnes si tu utilises Excel 2003 ou 16385 colonnes si tu disposes d'Excel 2010. Excel n'est pas un SGBD. Excel n'est qu'un traitement de texte rudimentaire. Si l'on excepte Office 2010 64 bits qui a d'autres inconvénients, Excel 2010 32 bits ne sait gérer que 2 Go de mémoire etc.

[Bluedeep]

Bonjour,

Si l'on excepte Office 2010 64 bits qui a d'autres inconvénients

Lesquels ? (ce n'est pas une question pour polémiquer, juste pour savoir).

[comme de bien entendu]

Bonjour,
Oui effectivement Excel n'est pas un traitement de texte, mais je pensais surtout au moment du choix sur le développement d'une application, où la question peut se poser : Excel, Java ou Autre...
En ce qui concerne les SGBD, Excel n'est certes pas une application de gestion de bases puissante, mais peut servir de frontal.
Dernièrement on vient de remplacer un script PHP qui moulinait par un modèle XLT, avec des SommeProd qui se lancent en une fraction de seconde.
J'ai l'impression que lorsque l'on cherche à faire efficace et rapide, le choix d'Excel peut être intéressant.
J'ai vu des équipes en salle de marché développer des moulinettes pour les traders en Excel/VBA.
Je cherche pas à polémiquer mais à montrer que l'on a un outils qui peut rendre beaucoup de services. (en ce moment j'en suis à ma quatrième application deployée pour la vente de matériels avec des interfaces graphiques très pratiques.)

[Didier Gonard]

Bonjour,

déjà à la base, il y a une énorme confusion !

Il ne faut pas confondre Excel et le VBA, aux niveaux Applis que tu cites, je te fais la même chose avec PowerPoint en pilotant Excel à partir du VBA PPT si besoin est.
Mon utilisateur incrédule ne verra que le fait qu'il lui faille ouvrir un fichier PPT pour faire tourner la chose

à partir de là, je peux manipuler des API etc... et je suis bien loin de l'application Office nommée Excel de base.

Reste en dernier lieu à ne pas confondre efficacité et efficience.

cordialement,

Didier

[ZebreLoup]

Je pense que le choix de la technologie va dépendre de l'ambition qu'on se donne et de la complexité du projet dans lequel on se lance.

Pour moi, le principal intérêt de VBA est qu'il est assez facile d'accès quand on débute. N'étant pas du tout informaticien de formation, j'ai commencé comme ça, un petit enregistreur de macro, la compréhension des variables, des objets, des procédures, des fonctions... C'est motivant car on peut faire des trucs sympa rapidement. Alors que rien que l'installation d'un environnement de développement peut s'avérer laborieux pour certains autres langages quand on n'est pas averti.
En plus, dans le monde de l'entreprise, Excel est très implanté et l'application sera sans doute accessible facilement pour l'utilisateur.

Je pense qu'on peut vraiment quasiment tout faire avec VBA, mais que ça peut devenir assez compliqué au bout d'un moment.
J'en arrive donc aux limites...

Tout d'abord le temps d'exécution par rapport à un langage compilé. J'ai commencé à programmer en C++, Java, C#, VB.Net pour cette raison. Dès qu'il y avait beaucoup de calculs, je passais d'un temps de traitement sous Excel de plusieurs minutes à seulement quelques secondes.

Ensuite, même s'il y a un modèle objet en VBA, il n'est pas complet. Et pour des applications plus élaborées, l'héritage, le polymorphisme, les interfaces... peuvent nous simplifier la vie. De même, on a souvent des fonctionnalités plus nombreuses incluses dans les frameworks. Je fais plutôt du C# maintenant, et j'avoue que maintenant que j'ai gouté aux joies de LINQ par exemple, j'ai du mal quand je reviens en VBA.

Pour conclure, comme toujours il y a du pour et du contre. Je pense qu'il faut limiter VBA à des applications pas trop complexes même si on peut aller assez loin avec.

[clementmarcotte]

Bonjour,

Bonjour,



Lesquels ? (ce n'est pas une question pour polémiquer, juste pour savoir).

À partir d'Office 2010, Office est disponible en versions 32 bits et 64 bits (pas juste Office 2010, mais tous les autres après, c'est pareil). Mais Microsoft n'a pas recompilé ses ActiveX VB6 et avant pour qu'ils soient compatibles avec les applications VBA à 64 bits. Donc Calendar, DateTimePicker, ListView et les autres ne peuvent pas être utilisés avec des versions 64 bits d'Office et c'est un vrai problème quand on a des parcs hétéroclites d'office 32 et 64 bits. Également, il y a des appels à l'API Windows qui doivent être réécrits.

Regarde ici pour pousser plus loin

[Invité]

Bonsoir,
Excel est un tableur et a pour vocation de gérer et organiser des tableaux.

bien sur il y a VBA qui permet d'étendre c'est possibilités. si on compare avec ACCESS qui est une base de données relationnelles, qui dispose également de VBA, d'un assistant de requêtage, d'un assistant de formulaire ,et peux exporter ses donnes vers EXCEL.... avec access on peut faire une application sens connaitre VBA!

il est vrai que certaine personnes
ne peuvent compter que sur EXCEL c'est déjà ça!