Discussion :

[hono]

visual basic ou visual basic office ou autre langage????
Bonjour
Je dois à partir de la saisie d'informations à l'écran, créer 1 document WORD et mettre à jour des tableaux Excel.
Quel langage dois je utiliser : VBA? VISUAL BASIC? ACCESS? MACROS?

[Heureux-oli]

un topo rapide.
Visual Basic est un langage qui permet de faire des applications qui vont tourner seules.

VBA, Visual Basic For Application est un langage qui a besoin d'une application hôte pour fonctionner. Cette application peut-être une application de la suite Office.

Si tu veux traiter des documents existants mais ne pas créer des document et ne pas générer une application propre, VBA est un très bon moyen.

Les macros sont une dérive de langage usuel. Une macro est un morceau de code qui tourne sous VBA. Pour Word ou Excel par exemple on peut les enregistrer mais on peut aussi les écrire.

Tu trouveras probablement quelques exemples qui pourront faire ton bonheur sur http://office.developpez.com/ et te rendre compte que si tu ne veux travailler que sur des fichiers office, tu n'as pas besoin de VB.

Mais c'est à toi de voir.

Si tu as des questions, nous sommes à ta disposition.

[Sepia]

Salut,

J'ajouterais juste à ce que t'a Heureux-Oli, le fait que dans VBA (VB pour Office) tu as un énorme modèle avec plein d'objets (avec leur méthodes) à disposition mais qui ne font pas toujours tout ce que tu voudrais. Donc d'un côté plein de trucs sympas (mais qu'il faut apprendre à connaître) de l'autre rien mais pas de contrainte sauf tes propres limites. Pour le VBA on peut t'aider mais rarement sauf pour des points précis à ta place (mais c'est pareil pour VB).

Voilà

[Maxence HUBICHE]

Personnellement, je ne partage pas l'avis de Sepia, étant donné que même VB repose sur VBA (il suffit de regarder les références du projet)
C'est le même langage
La différence vient surtout de l'interpréteur.

Dans un cas (VB) on a besoin de vbrun.dll, et cela permet l'exploitation d'un code pseudo-compilé (interprété) sous la forme d'un exe, d'une dll ou même d'un ocx.
Dans l'autre cas (VBA) l'interpréteur est intégré à l'application (d'où le A de VBA) et est nécessaire pour interpréter le code pseudo-compilé des modules du fichier concerné.

Dans les deux cas, donc, puisque c'est le même langage, la vraie différence tient en deux choses :
* l'interpréteur
* la capacité du développeur de trouver des solutions pour faire ce qu'il souhaite réaliser.

[Sepia]

Salut,

Non Maxence, oui la syntaxe est la même mais la différence fondamentale tient dans l'environnement de travail. Actuellement il n'existe pas de projet (d'envergure) dans lequel on n'utilise pas de bibliothèque. Or VB n'en fournit que pour des structures informatiques de base mais pas de composant pour manipuler les objets.

Que ferait-on en Java sans l'énorme bibliothèque des objets ? Que serait Linux sans la communauté ? Rien il n'est pas possible à un humain de faire une IHM sans une bibliothèque de GUI (même une moche comme celle de Microsoft, je ne te parle même pas de celle Apple ou KDE). A titre d'information, la dernière modification sur l'IHM de Vista (avec les corrections, je reconnais) a coûté à Microsoft 587 hommes/an (il faut vivre vieux pour y arriver). Donc maintenant sauf un petit truc, sans bibliothèque (ou modèle d'objet) pas de salut.

Donc si hono veut faire du Word avec du Excel, il faut qu'il fasse du VBA, parce que les composants sont utilisables directement (rien qu'un objet comme ActiveDocument c'est déjà monstrueux en terme de programmation objet) mais je reconnias qu'il peut le faire en VB ou en Java mais ce sera plus compliqué en terme de coût même si au départ, il doit apprendre (ce qui n'est pas négligeable le modèle des objets mais on est là pour ça ).

Maintenant mon opinion n'est qu'un avis, une recommandation d'habitué certes mais en aucun cas, cet avis n'a valeur de loi et celui de Maxence est aussi valable. Et de toute façon, nous essayerons (dans la mesure de nos connaissances) de t'aider, hono.

Tiens-nous au courant

[Maxence HUBICHE]

Salut Sepia !
Ce débat m'intéresse, et, si tu le veux bien, j'aimerai que nous le continuions, et le poussions un peu au bout.
Pourquoi pas, à terme, l'intégrer en tant que thread d'un forum Debats

Je vais donc reprendre une partie de ton discours et approfondir le pourquoi du comment de "je ne partage pas complètement ton point de vues" :

oui la syntaxe est la même

Au moins un point sur lequel nous sommes d'accord !

Actuellement il n'existe pas de projet (d'envergure) dans lequel on n'utilise pas de bibliothèque. Or VB n'en fournit que pour des structures informatiques de base mais pas de composant pour manipuler les objets.

Sauf erreur de ma part, l'intérêt même d'une bibliothèque est qu'elle soit développé par n'importe qui, pour être réutilisée par le développeur.

• Donc, quand on commence un projet VB, on commence avec la bibliothèque VBA (si si ), puis, on ajoute toutes les bibliothèquesdont on a besoin (Word, Excel,etc.) On peut même programmer en LateBinding, ce qui fait qu'on n'a pas besoin de référencer les bibliothèques.
• Quand on commence un projet VBA, on commence avec 2 bibliothèques (VBA + celle du logiciel dans leque on est), puis, on ajoute toutes les bibliothèquesdont on a besoin (Word, Excel,etc.) On peut même programmer en LateBinding, ce qui fait qu'on n'a pas besoin de référencer les bibliothèques.

Prenons un exemple.
Je suis dans VB, je veux piloter Excel, j'ajoute la bibliothèque Excel ou je programme en Late Binding
Je suis dans Word, je veux piloter Excel, j'ajoute la bibliothèque Excel ou je programme en Late Binding

Donc, on fait exactement la même chose dans les deux cas.

Vrai ou pas ?

[Sepia]

Salut Sepia !
Ce débat m'intéresse, et, si tu le veux bien, j'aimerai que nous le continuions, et le poussions un peu au bout.
Pourquoi pas, à terme, l'intégrer en tant que thread d'un forum Debats

Oui, tout à fait d'accord.

Sauf erreur de ma part, l'intérêt même d'une bibliothèque est qu'elle soit développé par n'importe qui, pour être réutilisée par le développeur.

• Donc, quand on commence un projet VB, on commence avec la bibliothèque VBA (si si ), puis, on ajoute toutes les bibliothèquesdont on a besoin (Word, Excel,etc.) On peut même programmer en LateBinding, ce qui fait qu'on n'a pas besoin de référencer les bibliothèques.
• Quand on commence un projet VBA, on commence avec 2 bibliothèques (VBA + celle du logiciel dans leque on est), puis, on ajoute toutes les bibliothèquesdont on a besoin (Word, Excel,etc.) On peut même programmer en LateBinding, ce qui fait qu'on n'a pas besoin de référencer les bibliothèques.

Prenons un exemple.
Je suis dans VB, je veux piloter Excel, j'ajoute la bibliothèque Excel ou je programme en Late Binding
Je suis dans Word, je veux piloter Excel, j'ajoute la bibliothèque Excel ou je programme en Late Binding

Donc, on fait exactement la même chose dans les deux cas.

Vrai ou pas ?

Oui, tout à fait d'accord. C'est plus un pb de prise en mains que technique, car c'est plus un problème est lié à l'environnement de développement c'est-à-dire à la fois à l'outil de développement (IDE), aux bibliothèques offertes qu'en termes de possibilités (qui au final, comme tu le dis, te donnent les mêmes possibilités mais plus ou moins facilement). Ainsi en VB, tu as des facilités pour dessiner des boîtes de dialogue perso, alors que dans VBA, tu as une facilité pour manipuler les boîtes existantes (et les actions qu'elles fournissent).

Le débat reste donc ouvert.

[Maxence HUBICHE]

Ainsi en VB, tu as des facilités pour dessiner des boîtes de dialogue perso, alors que dans VBA, tu as une facilité pour manipuler les boîtes existantes (et les actions qu'elles fournissent).

Quoi que ...
Dans Access, j'ai les formulaires
Dans les autres produits, j'ai la bibliothèque MSForms

Tout cela me permet de dessiner tranquillement mes boîtes de dialogue.

D'ailleurs, il est à noter que les formulaires d'Access sont beaucoup plus puissants que les forms de VB

D'accord aussi, ou pas ?

[Invité]

Bonjour

D'ailleurs, il est à noter que les formulaires d'Access sont beaucoup plus puissants que les forms de VB

Il m'est arrivé dans mon ancienne boite à avoir à faire de petites applications.
J'avais le choix entre VB6 et Access, sachant que les données étaient sous Access et que tous les postes étaient équipés (à part 2 ou trois) en runtime.

J'ai privilégié systématiquement Access pour son interface, les possibilités des formulaires et surtout pour la création des états par rapport à CrystalReport. Je n'utilisais VB6 que pour la mise à jour ou le dépannage d'applications existantes.

Rien que le fait de visualiser les données sous formes de tableaux (sous-formulaires en mode feuille de donnée), la programmation est quasiment inexistante (une requête, un champ pére fils bien renseigné et voilà).

Starec

[Heureux-oli]

Il y a les UserForm en VBA qui conviennent aussi !

[Maxence HUBICHE]

Vi vi Olivier

Dans les autres produits, j'ai la bibliothèque MSForms

[Sepia]

Salut les gars,

Hé bien la discussion (qui déborde du fil de base de hono, excuse-nous ) semble en intéresser plus d'un. Mais je crois que finalement c'est un vrai débat certes technique mais de fond : faut-il adapter l'existant à ses besoins (mais on risque d'être de réduire ses besoins) ou faire du sur-mesure (mais on risque alors d'être obligé de réinventer la roue) ? Et c'est bien le boulot des analystes d'évaluer le travail à faire pour donner aux chefs de projets (et de façon plus générale aux décideurs) les moyens de fazire un choix entre les 2 solutions voire d'une 3ieme solution mixte : une bibliothèque de base et de l'adaptation ciblée.

Sepia