Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Function, sub... où les mettre???

Function, sub... où les mettre???

12 réponses
Avatar
TouTi
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

--
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Zoury
Salut TouTi! :O)

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???



Si tu n'as pas découpé ton programme en classes, alors utilise des modules.
Tu peux même en faire plus d'un et regrouper les méthodes/fonctions qui
touche les même fonctionnalités ensemble. Un module est chargé en mémoire
dès que l'on appelle un de ses membres (variables, constantes, méthodes,
etc.), ainsi en regroupant, par exemple, les méthodes qui touche
l'impression dans un module et les méthodes qui concerne l'accès aux
fichiers dans un autre, ton application pourrait n'utiliser qu'une seule des
deux fonctionnalités sans encombrer la mémoire avec les fonctionnalités non
employées.

--
Cordialement
Yanick
MVP pour Visual Basic
Avatar
dark poulpo
pareil

--
-----
http://dark.freezee.org/
- Dark Update v1.1
- Dark Emule v0.44b r4
- Dark 3D-X (le desktop 3d pour windows) (----------> v0.7 beta dispo)
Avatar
ng
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


Avatar
Aski
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




Avatar
Jean-Marc
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
>
>




Avatar
Aski
Salut,

Ben, lorsque j'ai commencé avec l'appel Two et ses 64 Ko de RAM, on était
bien obligé de réduire le code, d'autant plus qu'il n'était pas compilé.
On allait même jusqu'à compresser les lignes, avec un petit utilitaire, pour
réduire le code.
C'était le bon temps ,-))

Aski

"Jean-Marc" a écrit dans le message de
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
> >
> >
>
>




Avatar
Patrice Henrio
Analyse très pertinente et intéressante. C'est vrai que le problème
essentiel c'est bien plutôt la lisibilité du code pour la maintenance.
Aujourd'hui nos machines ont de l'espace et le temps d'exécution est devenu
très secondaire.


"Jean-Marc" a écrit dans le message de 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
>
>








Avatar
Barsalou
Bonjour,

et encore l'Apple two était du luxe à côté de la HP41C, voire HP65, avec
laquelle beaucoup on fait leurs débuts en programmation !
On se cassait la tête pour économiser un octet où un cycle d'horloge.

Eric
Avatar
Aski
Bonjour Barsalou,

La programmation machine, c'était tout un art réservé à l'élite ..

Henri

"Barsalou" a écrit dans le message de
news:
Bonjour,

et encore l'Apple two était du luxe à côté de la HP41C, voire HP65, avec
laquelle beaucoup on fait leurs débuts en programmation !
On se cassait la tête pour économiser un octet où un cycle d'horloge.

Eric



Avatar
TouTi
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
> >
> >
>
>




1 2