Mon appli appelle pas mal de functions et subs. Pour ne pas trop charger la
mémoire, vaut-il mieux les placer dans la "form" affichée à l'écran(chargée)
ou dans un module???
Une dll est une librairie contenant un certain nombre de fonctions appelées depuis le programme. Les fonctions API sont des fonctions contenues dans des dll de windows, Shell32.dll par exemple. Il est intéressant de les appeler lorsqu'on ne peut pas créer de telles fonctions avec VB. Je n'utilise personnellement pas de dll VB, mais j'ai été amené à en programmer 2 en C++ parce qu'il n'existait pas d'API et que C++ est plus puissant que VB (moins limité). Je te conseille pour l'instant de ne penser dll que lorsque tu auras besoin de fonctions non accessibles directement par VB. Quand tu seras devenu un crack, tu ne poseras plus la question.
Aski
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de news:42022a6a$0$19421$
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form 2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et nommés selon l'utilité Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à mettre en oeuvre????
GuY
--
"Jean-Marc" a écrit dans le message news: 41ffd31b$0$319$ > Hello, > > pour résumer: > 1/ Limiter autant que possible les fonctions et varaiables publiques: > chaque unité (form, module,etc.) ne doit voir que ce qui lui est > nécessaire > > 2/ D'accord avec ng: utiliser les form pour l'interface, et dissocier autant > que faire ce peut le code applicatif de l'interface > > 3/ D'accord avec Aski: les modules qui appellent une fonction d'une
form,
> c'est > très laid. Il y a toujours moyen d'éviter ça. > > On ne paye pas plus cher à faire du code modulaire: ne pas hésiter à
faire
> de nombreux modules pour bien isoler les choses. Exemple trivial: une > fonction > de calcul matriciel n'a rien à faire dans une form. Elle doit aller dans un > module > genre "matrice.bas"; Dans ce module, on ne déclarera "public" que le strict > nécessaire > (l'API) et on veillera à déclarer "private" les fonctions de service.
Par
> exmple si > au passage on calcule un déterminant, mais que cette fonction est
purement
> interne, > on la gardera "private": les autres modules ne doivent pas la voir. > > Dans une certaine mesure, on se fiche de la taille mémoire (si on reste avec > des valeurs > raisonnnables, bien sur). Faire du code tout embrouillé pour gagner quelques > kilos de RAM > est un *très* mauvais calcul, et ce dans **tous** les cas. > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > > > "Aski" a écrit dans le message de > news:e$ > > Bonsoir, > > > > N'est-il pas également astucieux de placer les fonctions de façon à > limiter > > le nombre de variables et de fonctions publiques ? > > Ceci impose évidemment de déclarer correctement ces fonctions (ou
sub).
> > De plus, je pense souhaitable d'éviter d'appeler des fonctions d'une > feuille > > depuis un module afin d'éviter des appels tels que > > hRet = Forms(0).MaFonction (Mon parametre) > > > > Aski > > > > "ng" a écrit dans le message de > > news: > > > Salut, > > > > > > Les forms sont comparables à des classes, il est donc conseiller de les > > > utiliser au max pour l'interface et donc de séparer le code de > l'interface > > > du reste en utilisant des modules (ou modules de classes). > > > > > > Ca ne doit pas affecter bcp la rapidité mais c'est simplement une > > meilleure > > > manière de s'organiser. > > > > > > -- > > > Nicolas G. > > > FAQ VB : http://faq.vb.free.fr > > > API Guide : http://www.allapi.net > > > Google Groups : http://groups.google.fr/ > > > MZ-Tools : http://www.mztools.com/ > > > > > > TouTi wrote: > > > > Bonjour > > > > > > > > Mon appli appelle pas mal de functions et subs. Pour ne pas trop > > > > charger la mémoire, vaut-il mieux les placer dans la "form"
affichée
> > > > à l'écran(chargée) ou dans un module??? > > > > > > > > Merci > > > > > > > > GuY > > > > > > > > > > > >
Bonjour Guy,
Une dll est une librairie contenant un certain nombre de fonctions appelées
depuis le programme.
Les fonctions API sont des fonctions contenues dans des dll de windows,
Shell32.dll par exemple.
Il est intéressant de les appeler lorsqu'on ne peut pas créer de telles
fonctions avec VB.
Je n'utilise personnellement pas de dll VB, mais j'ai été amené à en
programmer 2 en C++ parce qu'il n'existait pas d'API et que C++ est plus
puissant que VB (moins limité).
Je te conseille pour l'instant de ne penser dll que lorsque tu auras besoin
de fonctions non accessibles directement par VB.
Quand tu seras devenu un crack, tu ne poseras plus la question.
Aski
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de
news:42022a6a$0$19421$8fcfb975@news.wanadoo.fr...
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form
2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et
nommés selon l'utilité
Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à
mettre en oeuvre????
GuY
--
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message news:
41ffd31b$0$319$ba620e4c@news.skynet.be...
> Hello,
>
> pour résumer:
> 1/ Limiter autant que possible les fonctions et varaiables publiques:
> chaque unité (form, module,etc.) ne doit voir que ce qui lui est
> nécessaire
>
> 2/ D'accord avec ng: utiliser les form pour l'interface, et dissocier
autant
> que faire ce peut le code applicatif de l'interface
>
> 3/ D'accord avec Aski: les modules qui appellent une fonction d'une
form,
> c'est
> très laid. Il y a toujours moyen d'éviter ça.
>
> On ne paye pas plus cher à faire du code modulaire: ne pas hésiter à
faire
> de nombreux modules pour bien isoler les choses. Exemple trivial: une
> fonction
> de calcul matriciel n'a rien à faire dans une form. Elle doit aller dans
un
> module
> genre "matrice.bas"; Dans ce module, on ne déclarera "public" que le
strict
> nécessaire
> (l'API) et on veillera à déclarer "private" les fonctions de service.
Par
> exmple si
> au passage on calcule un déterminant, mais que cette fonction est
purement
> interne,
> on la gardera "private": les autres modules ne doivent pas la voir.
>
> Dans une certaine mesure, on se fiche de la taille mémoire (si on reste
avec
> des valeurs
> raisonnnables, bien sur). Faire du code tout embrouillé pour gagner
quelques
> kilos de RAM
> est un *très* mauvais calcul, et ce dans **tous** les cas.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
> "Aski" <aski@free.com> a écrit dans le message de
> news:e$OvlpICFHA.520@TK2MSFTNGP09.phx.gbl...
> > Bonsoir,
> >
> > N'est-il pas également astucieux de placer les fonctions de façon à
> limiter
> > le nombre de variables et de fonctions publiques ?
> > Ceci impose évidemment de déclarer correctement ces fonctions (ou
sub).
> > De plus, je pense souhaitable d'éviter d'appeler des fonctions d'une
> feuille
> > depuis un module afin d'éviter des appels tels que
> > hRet = Forms(0).MaFonction (Mon parametre)
> >
> > Aski
> >
> > "ng" <ng@ngsoft-fr.com> a écrit dans le message de
> > news:OfTSihICFHA.2404@TK2MSFTNGP15.phx.gbl...
> > > Salut,
> > >
> > > Les forms sont comparables à des classes, il est donc conseiller de
les
> > > utiliser au max pour l'interface et donc de séparer le code de
> l'interface
> > > du reste en utilisant des modules (ou modules de classes).
> > >
> > > Ca ne doit pas affecter bcp la rapidité mais c'est simplement une
> > meilleure
> > > manière de s'organiser.
> > >
> > > --
> > > Nicolas G.
> > > FAQ VB : http://faq.vb.free.fr
> > > API Guide : http://www.allapi.net
> > > Google Groups : http://groups.google.fr/
> > > MZ-Tools : http://www.mztools.com/
> > >
> > > TouTi wrote:
> > > > Bonjour
> > > >
> > > > Mon appli appelle pas mal de functions et subs. Pour ne pas trop
> > > > charger la mémoire, vaut-il mieux les placer dans la "form"
affichée
> > > > à l'écran(chargée) ou dans un module???
> > > >
> > > > Merci
> > > >
> > > > GuY
> > >
> > >
> >
> >
>
>
Une dll est une librairie contenant un certain nombre de fonctions appelées depuis le programme. Les fonctions API sont des fonctions contenues dans des dll de windows, Shell32.dll par exemple. Il est intéressant de les appeler lorsqu'on ne peut pas créer de telles fonctions avec VB. Je n'utilise personnellement pas de dll VB, mais j'ai été amené à en programmer 2 en C++ parce qu'il n'existait pas d'API et que C++ est plus puissant que VB (moins limité). Je te conseille pour l'instant de ne penser dll que lorsque tu auras besoin de fonctions non accessibles directement par VB. Quand tu seras devenu un crack, tu ne poseras plus la question.
Aski
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de news:42022a6a$0$19421$
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form 2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et nommés selon l'utilité Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à mettre en oeuvre????
GuY
--
"Jean-Marc" a écrit dans le message news: 41ffd31b$0$319$ > Hello, > > pour résumer: > 1/ Limiter autant que possible les fonctions et varaiables publiques: > chaque unité (form, module,etc.) ne doit voir que ce qui lui est > nécessaire > > 2/ D'accord avec ng: utiliser les form pour l'interface, et dissocier autant > que faire ce peut le code applicatif de l'interface > > 3/ D'accord avec Aski: les modules qui appellent une fonction d'une
form,
> c'est > très laid. Il y a toujours moyen d'éviter ça. > > On ne paye pas plus cher à faire du code modulaire: ne pas hésiter à
faire
> de nombreux modules pour bien isoler les choses. Exemple trivial: une > fonction > de calcul matriciel n'a rien à faire dans une form. Elle doit aller dans un > module > genre "matrice.bas"; Dans ce module, on ne déclarera "public" que le strict > nécessaire > (l'API) et on veillera à déclarer "private" les fonctions de service.
Par
> exmple si > au passage on calcule un déterminant, mais que cette fonction est
purement
> interne, > on la gardera "private": les autres modules ne doivent pas la voir. > > Dans une certaine mesure, on se fiche de la taille mémoire (si on reste avec > des valeurs > raisonnnables, bien sur). Faire du code tout embrouillé pour gagner quelques > kilos de RAM > est un *très* mauvais calcul, et ce dans **tous** les cas. > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > > > "Aski" a écrit dans le message de > news:e$ > > Bonsoir, > > > > N'est-il pas également astucieux de placer les fonctions de façon à > limiter > > le nombre de variables et de fonctions publiques ? > > Ceci impose évidemment de déclarer correctement ces fonctions (ou
sub).
> > De plus, je pense souhaitable d'éviter d'appeler des fonctions d'une > feuille > > depuis un module afin d'éviter des appels tels que > > hRet = Forms(0).MaFonction (Mon parametre) > > > > Aski > > > > "ng" a écrit dans le message de > > news: > > > Salut, > > > > > > Les forms sont comparables à des classes, il est donc conseiller de les > > > utiliser au max pour l'interface et donc de séparer le code de > l'interface > > > du reste en utilisant des modules (ou modules de classes). > > > > > > Ca ne doit pas affecter bcp la rapidité mais c'est simplement une > > meilleure > > > manière de s'organiser. > > > > > > -- > > > Nicolas G. > > > FAQ VB : http://faq.vb.free.fr > > > API Guide : http://www.allapi.net > > > Google Groups : http://groups.google.fr/ > > > MZ-Tools : http://www.mztools.com/ > > > > > > TouTi wrote: > > > > Bonjour > > > > > > > > Mon appli appelle pas mal de functions et subs. Pour ne pas trop > > > > charger la mémoire, vaut-il mieux les placer dans la "form"
affichée
> > > > à l'écran(chargée) ou dans un module??? > > > > > > > > Merci > > > > > > > > GuY > > > > > > > > > > > >
Jean-Marc
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de news:42022a6a$0$19421$
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form 2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et nommés selon l'utilité Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à mettre en oeuvre????
Hello,
Dll, ça veut dire Dynamic Link Library. Les dll sont donc des librairies, des conteneurs de fonction. Dynamiques, ca veut dire que le programme principal ne doit pas inclure physiquement le code des fonctions pour fabriquer l'exécutable. Si on veut inclure le code dans un seul exécutable, on doit alors fabriquer une librairie statique et indiquer à l'éditeur de lien d'inclure le code dans l'exécutable. Windows utilise principalement le méchanisme des DLL, pour un ensemble de raisons (hors sujet ici).
Avec des langages comme C ou C++, on peut créer des fonctions, comme en VB, et les compiler toutes ensembles sous forme d'une librairie, dynamique ou non. VB s'interface facilement avec des dll, écrites en C ou en C++ par exemple, mais pas seulement. Quand doit on faire une dll externe plutôt que de coder en VB? Il peut y avoir plusieurs raisons, bonnes ou mauvaises d'ailleurs!
2 exemples classiques:
On veut en VB faire des appels de fonctions systèmes de bas niveau, mais la manipulation de ce ces fonctions, bien souvent écrites en C n'est pas commode. Hop, on se fabrique sa propre fonction en C, en lui choisissant une interface commode pour VB, et on compile le tout sous forme d'une dll.
Autre exemple: problème de performances. Certains traitements en VB ne sont pas efficaces, par exemple la manipulation de chaînes de caractères ou encore certaines fonctions arithmétiques. Dans ce cas, on écrit les 2 ou 3 fonctions critiques en C, et on fait une Dll. L'utilisation des fonctions d'une Dll en VB est très simple, et la création d'une Dll en C n'est pas compliquée non plus.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de
news:42022a6a$0$19421$8fcfb975@news.wanadoo.fr...
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form
2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et
nommés selon l'utilité
Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à
mettre en oeuvre????
Hello,
Dll, ça veut dire Dynamic Link Library. Les dll sont donc des
librairies, des conteneurs de fonction. Dynamiques, ca veut dire que le
programme principal ne doit pas inclure physiquement le code des
fonctions pour fabriquer l'exécutable. Si on veut inclure le code dans
un seul exécutable, on doit alors fabriquer une librairie statique et
indiquer à l'éditeur de lien d'inclure le code dans l'exécutable.
Windows utilise principalement le méchanisme des DLL, pour un ensemble
de raisons (hors sujet ici).
Avec des langages comme C ou C++, on peut créer des fonctions, comme en
VB, et les compiler toutes ensembles sous forme d'une librairie,
dynamique ou non. VB s'interface facilement avec des dll, écrites en C
ou en C++ par exemple, mais pas seulement. Quand doit on faire une dll
externe plutôt que de coder en VB? Il peut y avoir plusieurs raisons,
bonnes ou mauvaises d'ailleurs!
2 exemples classiques:
On veut en VB faire des appels de fonctions systèmes de bas niveau,
mais la manipulation de ce ces fonctions, bien souvent écrites en C
n'est pas commode. Hop, on se fabrique sa propre fonction en C, en lui
choisissant une interface commode pour VB, et on compile le tout sous
forme d'une dll.
Autre exemple: problème de performances. Certains traitements en VB ne
sont pas efficaces, par exemple la manipulation de chaînes de
caractères ou encore certaines fonctions arithmétiques. Dans ce cas, on
écrit les 2 ou 3 fonctions critiques en C, et on fait une Dll.
L'utilisation des fonctions d'une Dll en VB est très simple, et la
création d'une Dll en C n'est pas compliquée non plus.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"TouTi" <gelapplication[Nospam]@tiscali.fr> a écrit dans le message de news:42022a6a$0$19421$
Bon c'est bien ce qui me semblait, ayant découvert VB sur le tas j'ai peu
a
peu organiser mon code :
1) Ce qui est dévolue à une form, je le laisse dans la form 2) Ce qui se partage, je le mets dans un ou plusieurs modules organisés et nommés selon l'utilité Donc je suis pas trop dans l'erreur....
Par contre, quelle est l'utilité des dll et est-ce relativement simple à mettre en oeuvre????
Hello,
Dll, ça veut dire Dynamic Link Library. Les dll sont donc des librairies, des conteneurs de fonction. Dynamiques, ca veut dire que le programme principal ne doit pas inclure physiquement le code des fonctions pour fabriquer l'exécutable. Si on veut inclure le code dans un seul exécutable, on doit alors fabriquer une librairie statique et indiquer à l'éditeur de lien d'inclure le code dans l'exécutable. Windows utilise principalement le méchanisme des DLL, pour un ensemble de raisons (hors sujet ici).
Avec des langages comme C ou C++, on peut créer des fonctions, comme en VB, et les compiler toutes ensembles sous forme d'une librairie, dynamique ou non. VB s'interface facilement avec des dll, écrites en C ou en C++ par exemple, mais pas seulement. Quand doit on faire une dll externe plutôt que de coder en VB? Il peut y avoir plusieurs raisons, bonnes ou mauvaises d'ailleurs!
2 exemples classiques:
On veut en VB faire des appels de fonctions systèmes de bas niveau, mais la manipulation de ce ces fonctions, bien souvent écrites en C n'est pas commode. Hop, on se fabrique sa propre fonction en C, en lui choisissant une interface commode pour VB, et on compile le tout sous forme d'une dll.
Autre exemple: problème de performances. Certains traitements en VB ne sont pas efficaces, par exemple la manipulation de chaînes de caractères ou encore certaines fonctions arithmétiques. Dans ce cas, on écrit les 2 ou 3 fonctions critiques en C, et on fait une Dll. L'utilisation des fonctions d'une Dll en VB est très simple, et la création d'une Dll en C n'est pas compliquée non plus.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
