Discussion :

[spileo]

Bonsoir,

je fais tourner une macro qui doit consommer pas mal de mémoire. Aussi je commence à me poser la question de la mémoire disponible pour Excel.
J'ai essayé de voir la mémoire libre par Application.MemoryFree et la mémoire utilisée par Application.MemoryUsed.
J'ai fais la somme des deux pour trouver combien de mémoire était allouée à Excel mais voilà: je trouve dans les 4Mo ce qui me bien ridicule par rapport à la quantité de mémoire vive qu'on peut trouver sur les pc récents et surtout par rapport au gestionnaire des tâches qui m'indique 70Mo de mémoire utilisée par le processus Excel.exe.

Si c'est possible, je voudrais augmenter les ressources allouées à Excel.
J'ai pas trouvé beaucoup d'informations sur le forum donc si quelqu'un a des informations sur ce qui touche à la mémoire où des sources d'informations en rapport avec ce sujet je suis preneur.
Merci.

Merci.

[ouskel'n'or]

Je ne peux pas répondre à ta question.Cependant, il faut savoir que si tu déclares toutes tes variables, que tu n'as pas un grand nombre de variables Publique, chaque procédure n'utilise que la mémoire qui lui est nécessaire. La procédure sitôt quittée libère la place occupée. C'est pourquoi il est conseillé de structurer son code au maximum.
Si tu n'utilises pas de goto, ou uniquement pour sortir de procédure en cas d'erreur, tu ne devrais jamais avoir de pb. En tout cas, avec la version 2003, je n'en ai jamais eu malgré des codes de plus de 8000 lignes comportant des userforms chargés, une quantité de graphes, et une vingtaine de feuilles de données. Ce qui n'était pas le cas de la version 97 où je n'ai simplement pas réussi à faire tenir 120 graphes dans 30 feuilles sans aucune macro.
A toutes fins utiles

[Gamal le Celte]

Je pense que ce n'est pas une question de mémoire, mais bien un phénomène intrinsèque à Excel qui utilise beaucoup de ressources. Il faut dire aussi que MS Office n'est pas un système de développement, même si nous pouvons faire des macros évoluées. A un certain moment, je pense qu'il est préférable d'utiliser un vrai langage de développement (VB, Python, Delphi, C/C++…..) et de piloter Excel si nécessaire.

[spileo]

Bonsoir,
tout d'abord merci pour vos réponses.

Ousk, j'ai juste déclaré les worksheets (environ 25) les classeurs (3) et les quelques contrôles en Public car ils sont créés dynamiquement et je dois piéger des évènements qui ne sont pas ceux qui existent par défaut lorsqu'un contrôle est crée dynamiquement, donc qu'il faut réinventer (genre Exit pour un TextBox).

Gamal, l'avantage d'Excel c'est que tu n'as pas besoin d'un environnement spécifique ce qui revient donc moins cher aux entreprises, mais c'est vrai qu'un environnement dédié c'est bien mieux.

En explorant un peu les méthodes de VBProject, j'ai vu qu'il y en avait une qui s'appelait MakeCompiledFile et qui normalement est supposée faire une dll de la macro, mais je n'ai pas réussi à l'utiliser.

Est-ce que ça pourrait m'être utile?

A+.

[ouskel'n'or]

Je n'ai pas ça Tu as quelle version ?

[spileo]

j'ai la 2003, et toi?

Code :

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

1
2
 
Application.ActiveWorkbook.VBProject.MakeCompiledFile

[Gamal le Celte]

Gamal, l'avantage d'Excel c'est que tu n'as pas besoin d'un environnement spécifique ce qui revient donc moins cher aux entreprises, mais c'est vrai qu'un environnement dédié c'est bien mieux.

Il y a beaucoup de choses libres et gratuites qui fonctionne très bien dans un millieu professionnel, comme Python...... Mais......

[ouskel'n'or]

Désolé, je n'ai rien trouvé sur MakeCompiledFile. Sans doute dans la version 2007...
Bonne chance
Je garde un oeil sur la discussion