VBA-> VBA.exe???

Bonjour,

Je crois que le plus simple serait de rajouter une ligne au début de ta macro auto_open :

Application.Visible = False


Bien sûr ne pas oublier de rajouter :

Application.Visible = True

à la fermeture.

Tu crées ensuite un raccourci vers ton fichier XLS.

Bonne fin de journée.

Bonjour Sébastien, le Forum

Il n'y a pas de 'Vraie application VBA'

VBA signifie 'Visual Basic for Application'.

En fait VBA ne peut fonctionner qu'avec son application hôte (Excel, Word, PowerPoint, Outlook)

VBA est un descendant de VB et l'application n'est pas Visual Studio, mais Simplement VB (6.0). Par aileurs VBS est un descendant de VBA...

De là à mettre tes UserForm dans VB, ce n'est pas prévu, car tes UserForms de VBA/Excel dépendent de MSForm 2.0 qui est donc le package OCX et autres DLL pour VBA. Par contre le code en lui même est assez similaire, tu auras probablement plus d'objects ActiveX, que dans VBA, mais tu en aura aussi pas mal en moins... en tout cas pour ceux qui concernent Excel...

Enfin je ne sais pas quels sont tes besoins, mais si c'est juste pour masquer Excel, tu risques d'avoir à refaire une application complète.

Bon Aprèm
@+Thierry

Bonjour Alain, re Sébastien

En tant que contributeur 'occasionnel' (lol), je tiens à coeur que l'on évite de donner ici des informations erronées, incomplètes, ou dangereuses.

Pour la macro Autpen, si vous suivez ce Forum et l'ancien, pour moi, c'est totalement obsolete car remplacé depuis Excel 97 par les Macros évènementielles WorkBook_Open (par exemple), bien plus puissantes... De plus MicroSoft recommande de ne plus les employer ('Autpen' et 'Auto_Close')

Pour le fameux Application.Visible = False, oui amusez vous, mais surtout ne faites jamais circuler une appli basée la dessus ni dans votre entreprise, ni chez vos amis, et ni sur ce Forum. C'est le meilleur moyen de faire un gros sbinz sur les PCs si les codes qui suivent sont foireux, où si il y a simplement un plantage en cours d'utilisation.

Enfin vous faites comme vous voulez, mais un XLdien / XLdienne averti(e) en vaut deux !

@+Thierry

Message édité par: _Thierry, à: 08/03/2005 15:26

Salut Sébastien

Oulala, dans quelle galère tu veux t'embarquer là !
Bon, j'dramatise un peu mais comme l'a dit déjà _Thierry les forms ne sont pas compatible, et pour l'avoir déjà fait à de nombreuse reprise transférer du code (et a fortiori avec des USF) VBA vers VB et inversement est une galère très très chi...te !
L'autre truc, c'est qu'il va falloir achetre VB et que c'est pas donné. Et pis l'interface est pas tout à fait pareil.
Bon ok, tu peux gérer XL depuis VB et donc d'une appli que tu auras créée, mais c'est un peu lourdingue. Donc mieux vaut développer un bon programme sur XL pour XL qu'un truc sur VB pour XL.

Bref, je t'invite à approfondir tes connaissances sous vbA quitte à ce que plus tard ta nouvelle vocation de programmeur t'oblige à investir dans VB (entre nous, va falloir plutôt penser VB.NET).

Bonjour,

J'ai pour des raisons souvent incomprises de certains utilisateurs de mes programmes été obligé de migrer des appli VBA Excel vers VB.Net avec un executable et setup d'installation très pro à la clé.

Investissement : 150 € pour VB.NEt à la FNAC ou ailleurs

En tous cas, grosse galère de travail pour migrer une appli Excel.

Pour moi, par ex. une appli avec 5 USF, une Base de données manipulable (extraction, filtres, etc...) et 2 graphs : créé sous Excel en 1 bonne journée = 10 jours de boulot sous VB.NET.
Mais je suis assez débutant en VB Net.

A savoir que VB.net n'a pas de feuilles de calcul intégrées qui font un paquet de boulot assez rapidement comme excel. Il existe des composants Spread pour simplifier la tâche.
De même, que l'exploitation d'une BDD en graphiques ou diverses éditions est carrément lourde à générer sous VB. NEt, encore des composants à rajouter ou Crystal Reports (bonjour la formation).

Et en ce qui concerne la logique VBA n'est pas forcément transposable sous VB.NET...

Voilà pour mon expérience dans le domaine.

A bientôt et Bon courage

Bonsoir le forum

Merci de m'avoir répondu, j'ai peut être été un peu maladroit dans mes propos.

Mon soucis réside dans le fait que j'ai du developper à partir de fichiers existants Excel une sorte d'application : J'ai donc créer des USf que j'affiche en plein écran etc...Le problème qui se pose à moi est que le temps d'ouverture des fichiers et réalisations des macros devient important et je voulais savoir si le fait de 'migrer' sous VB en créant un .exe qui aurait l avantage d'être autonome pourrait me permettre un gain de temps? :woohoo:

SAlut Sebastien.

Il existe peut-être une solution :

Comme me l'a conseiller : MrExcel sur le post :
Lien supprimé

L'optimisation du codes pourrait peut-être te permetre de gagner du temps d'exploitation.

A+