Discussion :

[Didier Gonard]

Bonjour,

Faisant des recherches, à la pause, sur l’optimisation vba, je suis tombé sur :

http://msdn.microsoft.com/en-us/libr...ice.10%29.aspx

qui m’a mené à :

http://msdn.microsoft.com/en-us/libr...ice.10%29.aspx

.../... Be aware of how much memory each data type requires and what range of values it can store. Always use a smaller data type if possible, except in the case where using a smaller data type will force an implicit conversion. For example, because variables of type Integer are converted to variables of type Long, it makes sense to declare variables that will store integer values as type Long instead of as type Integer. .../...

Et à :

http://msdn.microsoft.com/en-us/libr...ice.10%29.aspx

Qui dit clairement que les versions récentes il est inutile et même préjudiciable de déclarer des variables en Integer vu qu’elles sont de toutes façons converties en Long, et que du coup on y perd en performance ????

Qu'en pensez-vous ?

codialement,

Didier

[Domi2]

Bonjour,

Effectivement, cela fait déjà un certain temp que je pratique de cette manière, suite à la lecture de ce tutoriel, entre autre : Guide d'optimisation de vos applications Microsoft ACCESS, III-H. VBA.

Du coup, les seules variables typées Integer que j'utilise sont celles déclarées automatiquement dans les procédures (...Cancel As Integer).

Domi2

[Didier Gonard]

Vu,

Effectivement, et il y d'autres item généraux vba intéressants , maintenant je sais comment y avoir Accès

cordialement,

Didier

[Jean-Philippe André]

Salut,
tu me fais découvrir l'obsolécence potentielle des types de variables

Le changement dans la programmation est difficile à ce niveau là (comme on peut le ressentir en passant de DAO à ADO notamment), mais si on peut l'appliquer sur une nouvelle application plutôt que d'avoir à modifier des codes existant.

Et donc la fonction CInt() sera elle aussi remplacée à terme par CLng() ?

[Didier Gonard]

Bonjour,

Oui, ça fait bizarre, surtout quand on s'est efforcé pendant longtemps d'appliquer "les bonnes pratiques"

C'est comme on rencontre toujours à tout bout de champs dans les fils des notations du genre Range("A65536").End(xlUp) qui sont aussi obsolètes depuis 2 ans et au final plus dangereuses et devraient systématiquement être remplacées par des Cells(Rows.Count, colonne).End(xlUp).Row qui s'affranchissent du nombre de lignes de 2007... voir 2010 qui donne dans le gigantisme.

On ne doit pas faire de "la résistance au changement", on a assez de mal avec les clients à ce niveau

cordialement,

Didier

[Pierre Fauconnier]

Salut...

Dans la même idée de codes génériques qui deviendraient des "bonnes pratiques",
le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Cells(Rows.Count, colonne).End(xlUp).Row

peut planter lorsque la feuille active n'est pas une worksheet...

Si ce code est utilisé avec une feuile graphe active, => plantage

Donc, lorsque l'on utilise ce code en dehors d'un module de feuille, on aurait intérêt à préfixer Rows d'un objet Worksheet valide...