Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office Access largeur d'un formulaire

largeur d'un formulaire

31 réponses
Avatar
phil
Je voulais faire une barre de menus personnalis=E9e. je sais=20
qu'il est possible de le faire, mais j'ai pr=E9f=E9r=E9 r=E9aliser=20
un formulaire ind=E9pendant, qui se place en haut de la=20
fen=EAtre...=20
J'ai cependant un probl=E8me : comment puis-je faire que mon=20
formulaire ait la largeur de la fen=EAtre ?=20
Je voudrais faire qu'il soit comme une vraie barre de=20
menu...=20

Merci de me r=E9pondre.
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 3 4
Avatar
phil
Je n'ai pas que les lignes, à réduire, mais aussi le temps
de travail...

Si je fais ca sur un bouton, et que j'en fais 279 copies,
les 280 bouton auront-ils cela ?

Moi, en utilisant Excel, j'ai juste eu à faire "Coller
vers le bas", puis un Copier - Coller vers VB, et c'était
fini !!!

je préfère avoir 3 fois 280 lignes, que devoir recopier
280 fois le même truc (même en faisant copier-coller).
Rien que pour changer les noms des boutons, ca m'a saoule,
alors...

Mais merci de proposer des idées, c'est comme ca qu'on
trouve les meilleures solutions !
Phil

-----Message d'origine-----
Re,

Déjà pour retirer 3 lignes de code par boutons, tu peux
au lieu

d'utiliser une procédure évenementielle comme tu le
décris,

mettre directement dans la propriété "sur click" de ton
bouton :


=Proc(X)

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit dans
le message news:

1697801c41c99$a3629f20$
je suis également d'accord... il faut faire le moins de
lignes possible... mais pour moi, ca ne compte que lorsque
l'on n'utilise que VB !!!

J'essaye de simplifier tout ce que je peux... mais
lorsqu'il faut vérifier la saisie d'un utilisateur, il
faut bien tester toutes les valeurs : savoir si la valeur
est nulle, supérieure ou inférieure à telle ou telle autre
valeur...

et puis quand on gère près de 300 boutons (style
calendrier mais en mieux), on n'a pas le choix, c'est
long !!!
Pour gérer les évènements SurClic de 280 boutons, j'ai
juste eu besoin de quatre lignes par bouton (1 :
initialisation d'un tableau de boutons, 2 : "Sub
buttonX.clic", 3 : "call proc(X)" et 4 : "End Sub"), +
quelques lignes de traitement, communes à tous les
boutons...

J'ai pas encore trouvé mieux... mais si vous avez,
n'hésitez pas !
Je n'ai rien de mieux à faire qu'apprendre...

Phil


-----Message d'origine-----
Entièrement d'accord...
Moins y a de ligne, mieux je me porte, le seul truc par
contre,

c'est que je préfère quelques ligne de code plutôt que
d'utiliser

des macros...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"www.eztree-msdn.com ( Laurent Jordi )"
a écrit dans le

message news:
Bon courrage...

Personellement je trouve que l'informatique devient un
art quand en 3


ligne
on parvient à faire ce que d'autres font en 50...

@+

LJ
www.eztree-msdn.com



"Jessy Sempere [MVP]" a
écrit dans le message


de
news:c50gjp$hrp$
Bonjour

Mais pourquoi utilises tu Access dans ce cas ???

Sinon tu peux regarder la fonction MoveSize() pour
redimenssionner



ton formulaire...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit
dans le message



news:
195dc01c41c7f$4b4342a0$
En fait, moi je ne suis pas du tout un développeur
Access.



Ma spécialité, c'est plutot du développement sur
Visualbasic.Net.
je suis ce qu'on appelle un "pisseur de lignes".

Avec Access, on peut faire des formulaires basés sur
des



requetes pour voir les enregistrements ? Tant pis !
Je




n'utilise pas de requete, et je gère tout en code VB,
avec



mes boutons perso, des textbox indépendants, etc.

Tu vois, la base de données sur laquelle je travaille
aura



bientôt 10000 lignes de code VB...
En fait, je n'aime pas du tout laisser Access
s'occuper de



tout... Je court-circuite toutes les "fonctions
intrinsèques"...


Pour que mon "formulaire / barre de menu" reste au-
dessus



de tous les autres, j'ai mis la propriété
FenIndépendante



à Oui, et ca marche impeccable. Il ne me manque plus
que



la gestion de sa largeur...



-----Message d'origine-----
Re,

Je pense que tu détourne et complique l'utilisation
d'access pour rien et

donc prend un gros risque. Un bon developpeur access
ne




code quasiement
rien... Il faut au mximum utiliser les fonctions
Intrinsèques. Pourqoi ne

ferais-tu pas une toute petite fenêtre flottante,
comme




le compagnon office
pour afficher ces éléments ?

Tu pourrais ainsi créer ton menu avec access et
respecter




l'esprit dans
lequel il a été créé. Tu prendrais beaucoup moins de
risque.


En plus tu risque d'avoir des problèmes pour essayer
de




faire des menus qui
passeraient au dessus d'un autre formulaire...

@+

LJ
www.eztree-msdn.com
www.ezlogic.mc


"phil" a écrit
dans




le message de
news:194db01c41c76$19531350$

C'est pour pouvoir insérer des images, et afficher
une




textbox (pour afficher le nom de l'utilisateur en
cours).







-----Message d'origine-----
Salut,

Pourquoi ne personalises-tu pas simplement tes
menus ?






@+

LJ
www.eztree-msdn.com

"phil" a
écrit dans





le message de
news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus personnalisée.
je





sais
qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut de
la





fenêtre...
J'ai cependant un problème : comment puis-je faire
que





mon
formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie barre
de





menu...

Merci de me répondre.


.




.










.




.








Avatar
www.eztree-msdn.com \( Laurent Jordi \)
280 boutons ...

Tu devrais installer Notron System Works pour surveiller tes ressources
système GDI et UTIL en particulier. Si tu bosses sous NT4, 2000 ou XP ça ne
devrait pas poser de PB
Sous windows 98 sir tu ouvres ton formulaire alors que outlook (pas express)
est ouvert tu pourrais avoir de méchantes surprises...

Je pense que quelque soit l'appli que tu développe, si tu as mis 280 x le
même controle sur un formulaire c'est que ton truc n'est pas très bien
optimisé.

Un utilisateur ne peux pas saisir simultanément dans 280 Text box...

Dans un cas comme celui ci, j'aurais utilisé une technique sililaire a
celle utilisée dans les sites Web pour éditer les lignes d'un formulaire.

Tu crée une ligne de bouton et de text box. A chaque fois que l'utilisateur
change d'enregistrement, tu recopie les valeurs de l'enregistrement dans la
ligne d'édition.

Tu n'auras plus qu'1 text box par champ de ta vue, un bouton Valider 1
bouton Annuler et éventuellement un bouton supprimé.

Je ne connais pas précisément ton appli mais si un mec de mes équipes fait
ça, je lui fait faire autant de pompes que de contrôle innutile sur le
formulaire... ;)

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans le message de
news:14ef701c41c9d$e7aaf340$
je ne me suis pas trop penché la-dessus...
1) L'utilisateur saisit. il met n'importe quoi si il veut,
je m'en fout.
2) L'utilisateur appuie sur OK. Access vérifie tout d'un
coup et montre ce qui ne va pas...

Mais comment tu ferais pour gérer un tableau de 280
boutons ou 280 textbox, comme j'avais à faire ?

phil



-----Message d'origine-----
Re re re re

Et les règles de validation des champs elles sont faite
pour qui ?

Si tu remplis corectement le champs

Valide Si pour chaque champ de tes tables et que tu
saisis correctement les

messages d'erreur... Un gestion d'erreur suffit... 5 à 10
lignes en fonction

des détails que tu peux afficher...

Tu peux créer un module qui valide tous tes champs et qui
est

systématiquement appelé en cas d'erreur.

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:1697801c41c99$a3629f20$
je suis également d'accord... il faut faire le moins de
lignes possible... mais pour moi, ca ne compte que lorsque
l'on n'utilise que VB !!!

J'essaye de simplifier tout ce que je peux... mais
lorsqu'il faut vérifier la saisie d'un utilisateur, il
faut bien tester toutes les valeurs : savoir si la valeur
est nulle, supérieure ou inférieure à telle ou telle autre
valeur...

et puis quand on gère près de 300 boutons (style
calendrier mais en mieux), on n'a pas le choix, c'est
long !!!
Pour gérer les évènements SurClic de 280 boutons, j'ai
juste eu besoin de quatre lignes par bouton (1 :
initialisation d'un tableau de boutons, 2 : "Sub
buttonX.clic", 3 : "call proc(X)" et 4 : "End Sub"), +
quelques lignes de traitement, communes à tous les
boutons...

J'ai pas encore trouvé mieux... mais si vous avez,
n'hésitez pas !
Je n'ai rien de mieux à faire qu'apprendre...

Phil


-----Message d'origine-----
Entièrement d'accord...
Moins y a de ligne, mieux je me porte, le seul truc par
contre,

c'est que je préfère quelques ligne de code plutôt que
d'utiliser

des macros...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"www.eztree-msdn.com ( Laurent Jordi )"
a écrit dans le

message news:
Bon courrage...

Personellement je trouve que l'informatique devient un
art quand en 3


ligne
on parvient à faire ce que d'autres font en 50...

@+

LJ
www.eztree-msdn.com



"Jessy Sempere [MVP]" a
écrit dans le message


de
news:c50gjp$hrp$
Bonjour

Mais pourquoi utilises tu Access dans ce cas ???

Sinon tu peux regarder la fonction MoveSize() pour
redimenssionner



ton formulaire...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit
dans le message



news:
195dc01c41c7f$4b4342a0$
En fait, moi je ne suis pas du tout un développeur
Access.



Ma spécialité, c'est plutot du développement sur
Visualbasic.Net.
je suis ce qu'on appelle un "pisseur de lignes".

Avec Access, on peut faire des formulaires basés sur
des



requetes pour voir les enregistrements ? Tant pis !
Je




n'utilise pas de requete, et je gère tout en code VB,
avec



mes boutons perso, des textbox indépendants, etc.

Tu vois, la base de données sur laquelle je travaille
aura



bientôt 10000 lignes de code VB...
En fait, je n'aime pas du tout laisser Access
s'occuper de



tout... Je court-circuite toutes les "fonctions
intrinsèques"...


Pour que mon "formulaire / barre de menu" reste au-
dessus



de tous les autres, j'ai mis la propriété
FenIndépendante



à Oui, et ca marche impeccable. Il ne me manque plus
que



la gestion de sa largeur...



-----Message d'origine-----
Re,

Je pense que tu détourne et complique l'utilisation
d'access pour rien et

donc prend un gros risque. Un bon developpeur access
ne




code quasiement
rien... Il faut au mximum utiliser les fonctions
Intrinsèques. Pourqoi ne

ferais-tu pas une toute petite fenêtre flottante,
comme




le compagnon office
pour afficher ces éléments ?

Tu pourrais ainsi créer ton menu avec access et
respecter




l'esprit dans
lequel il a été créé. Tu prendrais beaucoup moins de
risque.


En plus tu risque d'avoir des problèmes pour essayer
de




faire des menus qui
passeraient au dessus d'un autre formulaire...

@+

LJ
www.eztree-msdn.com
www.ezlogic.mc


"phil" a écrit
dans




le message de
news:194db01c41c76$19531350$

C'est pour pouvoir insérer des images, et afficher
une




textbox (pour afficher le nom de l'utilisateur en
cours).







-----Message d'origine-----
Salut,

Pourquoi ne personalises-tu pas simplement tes
menus ?






@+

LJ
www.eztree-msdn.com

"phil" a
écrit dans





le message de
news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus personnalisée.
je





sais
qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut de
la





fenêtre...
J'ai cependant un problème : comment puis-je faire
que





mon
formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie barre
de





menu...

Merci de me répondre.


.




.










.




.








Avatar
phil
en fait, c'est une gestion des congés pour une entreprise.
L'utilisateur bossait sur un document excel, avant. Et il
veut tout avoir sous les yeux.

En colonnes : les dates (4 semaines). En lignes : les
travailleurs (limités à 10 : on peut basculer de l'un à
l'autre avec des bouton haut et bas).
Et dans les cases au milieu, des petites croix pour savoir
si machin est en congé tel jour.
L'utilisateur veut tout voir en même temps pour savoir
quand l'employé M. Machin prend ses congés, et si tout le
monde n'est pas en congé en même temps avant Noël (ce
serait génant) : ils bossent en 24h/24.

Lorsque j'enregistre, je ne crée pas un enregistrement par
employé et par date, mais un enregistrement par jour de
congés pris (par petite croix)...
J'avais pas envie de me creuser la tête à faire un
truc "plus simple". C'était un peu lourd, mais avec un
café, j'ai pu faire l'aspect graphique en une matinée...
Et j'ai mis l'après-midi à faire du code pour enregistrer
et annuler les modifications...

mais j'avoue !!! J'ai surtout improvisé.

phil



-----Message d'origine-----
280 boutons ...

Tu devrais installer Notron System Works pour surveiller
tes ressources

système GDI et UTIL en particulier. Si tu bosses sous
NT4, 2000 ou XP ça ne

devrait pas poser de PB
Sous windows 98 sir tu ouvres ton formulaire alors que
outlook (pas express)

est ouvert tu pourrais avoir de méchantes surprises...

Je pense que quelque soit l'appli que tu développe, si tu
as mis 280 x le

même controle sur un formulaire c'est que ton truc n'est
pas très bien

optimisé.

Un utilisateur ne peux pas saisir simultanément dans 280
Text box...


Dans un cas comme celui ci, j'aurais utilisé une
technique sililaire a

celle utilisée dans les sites Web pour éditer les lignes
d'un formulaire.


Tu crée une ligne de bouton et de text box. A chaque fois
que l'utilisateur

change d'enregistrement, tu recopie les valeurs de
l'enregistrement dans la

ligne d'édition.

Tu n'auras plus qu'1 text box par champ de ta vue, un
bouton Valider 1

bouton Annuler et éventuellement un bouton supprimé.

Je ne connais pas précisément ton appli mais si un mec de
mes équipes fait

ça, je lui fait faire autant de pompes que de contrôle
innutile sur le

formulaire... ;)

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:14ef701c41c9d$e7aaf340$
je ne me suis pas trop penché la-dessus...
1) L'utilisateur saisit. il met n'importe quoi si il veut,
je m'en fout.
2) L'utilisateur appuie sur OK. Access vérifie tout d'un
coup et montre ce qui ne va pas...

Mais comment tu ferais pour gérer un tableau de 280
boutons ou 280 textbox, comme j'avais à faire ?

phil



-----Message d'origine-----
Re re re re

Et les règles de validation des champs elles sont faite
pour qui ?

Si tu remplis corectement le champs

Valide Si pour chaque champ de tes tables et que tu
saisis correctement les

messages d'erreur... Un gestion d'erreur suffit... 5 à 10
lignes en fonction

des détails que tu peux afficher...

Tu peux créer un module qui valide tous tes champs et qui
est

systématiquement appelé en cas d'erreur.

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:1697801c41c99$a3629f20$
je suis également d'accord... il faut faire le moins de
lignes possible... mais pour moi, ca ne compte que
lorsque


l'on n'utilise que VB !!!

J'essaye de simplifier tout ce que je peux... mais
lorsqu'il faut vérifier la saisie d'un utilisateur, il
faut bien tester toutes les valeurs : savoir si la valeur
est nulle, supérieure ou inférieure à telle ou telle
autre


valeur...

et puis quand on gère près de 300 boutons (style
calendrier mais en mieux), on n'a pas le choix, c'est
long !!!
Pour gérer les évènements SurClic de 280 boutons, j'ai
juste eu besoin de quatre lignes par bouton (1 :
initialisation d'un tableau de boutons, 2 : "Sub
buttonX.clic", 3 : "call proc(X)" et 4 : "End Sub"), +
quelques lignes de traitement, communes à tous les
boutons...

J'ai pas encore trouvé mieux... mais si vous avez,
n'hésitez pas !
Je n'ai rien de mieux à faire qu'apprendre...

Phil


-----Message d'origine-----
Entièrement d'accord...
Moins y a de ligne, mieux je me porte, le seul truc par
contre,

c'est que je préfère quelques ligne de code plutôt que
d'utiliser

des macros...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"www.eztree-msdn.com ( Laurent Jordi )"




a écrit dans le
message news:
Bon courrage...

Personellement je trouve que l'informatique devient un
art quand en 3


ligne
on parvient à faire ce que d'autres font en 50...

@+

LJ
www.eztree-msdn.com



"Jessy Sempere [MVP]" a
écrit dans le message


de
news:c50gjp$hrp$
Bonjour

Mais pourquoi utilises tu Access dans ce cas ???

Sinon tu peux regarder la fonction MoveSize() pour
redimenssionner



ton formulaire...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit
dans le message



news:
195dc01c41c7f$4b4342a0$
En fait, moi je ne suis pas du tout un développeur
Access.



Ma spécialité, c'est plutot du développement sur
Visualbasic.Net.
je suis ce qu'on appelle un "pisseur de lignes".

Avec Access, on peut faire des formulaires basés sur
des



requetes pour voir les enregistrements ? Tant pis !
Je




n'utilise pas de requete, et je gère tout en code
VB,





avec
mes boutons perso, des textbox indépendants, etc.

Tu vois, la base de données sur laquelle je
travaille





aura
bientôt 10000 lignes de code VB...
En fait, je n'aime pas du tout laisser Access
s'occuper de



tout... Je court-circuite toutes les "fonctions
intrinsèques"...


Pour que mon "formulaire / barre de menu" reste au-
dessus



de tous les autres, j'ai mis la propriété
FenIndépendante



à Oui, et ca marche impeccable. Il ne me manque plus
que



la gestion de sa largeur...



-----Message d'origine-----
Re,

Je pense que tu détourne et complique l'utilisation
d'access pour rien et

donc prend un gros risque. Un bon developpeur
access






ne
code quasiement
rien... Il faut au mximum utiliser les fonctions
Intrinsèques. Pourqoi ne

ferais-tu pas une toute petite fenêtre flottante,
comme




le compagnon office
pour afficher ces éléments ?

Tu pourrais ainsi créer ton menu avec access et
respecter




l'esprit dans
lequel il a été créé. Tu prendrais beaucoup moins
de






risque.

En plus tu risque d'avoir des problèmes pour
essayer






de
faire des menus qui
passeraient au dessus d'un autre formulaire...

@+

LJ
www.eztree-msdn.com
www.ezlogic.mc


"phil" a
écrit






dans
le message de
news:194db01c41c76$19531350$

C'est pour pouvoir insérer des images, et afficher
une




textbox (pour afficher le nom de l'utilisateur en
cours).







-----Message d'origine-----
Salut,

Pourquoi ne personalises-tu pas simplement tes
menus ?






@+

LJ
www.eztree-msdn.com

"phil" a
écrit dans





le message de
news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus personnalisée.
je





sais
qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut de
la





fenêtre...
J'ai cependant un problème : comment puis-je faire
que





mon
formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie barre
de





menu...

Merci de me répondre.


.




.










.




.




.









Avatar
www.eztree-msdn.com \( Laurent Jordi \)
Re

chez moi tu aurais de ces triceps...

C'est vrai que tu n'as pas beaucoup de souplesse avec Access... néanmoins,
l'utilisation soux d'un formulaire tabulaire continu aurrait surement pu
faire l'affaire...

Personellement j'aurais gardé Excel pour l'interface IHM et l'aurais
connecté via DAO à la base Access... A moins qu'excel te donnes des
boutons...

@+

LJ
www.eztree-msdn.com



"phil" a écrit dans le message de
news:196c801c41ca4$265b04d0$
en fait, c'est une gestion des congés pour une entreprise.
L'utilisateur bossait sur un document excel, avant. Et il
veut tout avoir sous les yeux.

En colonnes : les dates (4 semaines). En lignes : les
travailleurs (limités à 10 : on peut basculer de l'un à
l'autre avec des bouton haut et bas).
Et dans les cases au milieu, des petites croix pour savoir
si machin est en congé tel jour.
L'utilisateur veut tout voir en même temps pour savoir
quand l'employé M. Machin prend ses congés, et si tout le
monde n'est pas en congé en même temps avant Noël (ce
serait génant) : ils bossent en 24h/24.

Lorsque j'enregistre, je ne crée pas un enregistrement par
employé et par date, mais un enregistrement par jour de
congés pris (par petite croix)...
J'avais pas envie de me creuser la tête à faire un
truc "plus simple". C'était un peu lourd, mais avec un
café, j'ai pu faire l'aspect graphique en une matinée...
Et j'ai mis l'après-midi à faire du code pour enregistrer
et annuler les modifications...

mais j'avoue !!! J'ai surtout improvisé.

phil



-----Message d'origine-----
280 boutons ...

Tu devrais installer Notron System Works pour surveiller
tes ressources

système GDI et UTIL en particulier. Si tu bosses sous
NT4, 2000 ou XP ça ne

devrait pas poser de PB
Sous windows 98 sir tu ouvres ton formulaire alors que
outlook (pas express)

est ouvert tu pourrais avoir de méchantes surprises...

Je pense que quelque soit l'appli que tu développe, si tu
as mis 280 x le

même controle sur un formulaire c'est que ton truc n'est
pas très bien

optimisé.

Un utilisateur ne peux pas saisir simultanément dans 280
Text box...


Dans un cas comme celui ci, j'aurais utilisé une
technique sililaire a

celle utilisée dans les sites Web pour éditer les lignes
d'un formulaire.


Tu crée une ligne de bouton et de text box. A chaque fois
que l'utilisateur

change d'enregistrement, tu recopie les valeurs de
l'enregistrement dans la

ligne d'édition.

Tu n'auras plus qu'1 text box par champ de ta vue, un
bouton Valider 1

bouton Annuler et éventuellement un bouton supprimé.

Je ne connais pas précisément ton appli mais si un mec de
mes équipes fait

ça, je lui fait faire autant de pompes que de contrôle
innutile sur le

formulaire... ;)

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:14ef701c41c9d$e7aaf340$
je ne me suis pas trop penché la-dessus...
1) L'utilisateur saisit. il met n'importe quoi si il veut,
je m'en fout.
2) L'utilisateur appuie sur OK. Access vérifie tout d'un
coup et montre ce qui ne va pas...

Mais comment tu ferais pour gérer un tableau de 280
boutons ou 280 textbox, comme j'avais à faire ?

phil



-----Message d'origine-----
Re re re re

Et les règles de validation des champs elles sont faite
pour qui ?

Si tu remplis corectement le champs

Valide Si pour chaque champ de tes tables et que tu
saisis correctement les

messages d'erreur... Un gestion d'erreur suffit... 5 à 10
lignes en fonction

des détails que tu peux afficher...

Tu peux créer un module qui valide tous tes champs et qui
est

systématiquement appelé en cas d'erreur.

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:1697801c41c99$a3629f20$
je suis également d'accord... il faut faire le moins de
lignes possible... mais pour moi, ca ne compte que
lorsque


l'on n'utilise que VB !!!

J'essaye de simplifier tout ce que je peux... mais
lorsqu'il faut vérifier la saisie d'un utilisateur, il
faut bien tester toutes les valeurs : savoir si la valeur
est nulle, supérieure ou inférieure à telle ou telle
autre


valeur...

et puis quand on gère près de 300 boutons (style
calendrier mais en mieux), on n'a pas le choix, c'est
long !!!
Pour gérer les évènements SurClic de 280 boutons, j'ai
juste eu besoin de quatre lignes par bouton (1 :
initialisation d'un tableau de boutons, 2 : "Sub
buttonX.clic", 3 : "call proc(X)" et 4 : "End Sub"), +
quelques lignes de traitement, communes à tous les
boutons...

J'ai pas encore trouvé mieux... mais si vous avez,
n'hésitez pas !
Je n'ai rien de mieux à faire qu'apprendre...

Phil


-----Message d'origine-----
Entièrement d'accord...
Moins y a de ligne, mieux je me porte, le seul truc par
contre,

c'est que je préfère quelques ligne de code plutôt que
d'utiliser

des macros...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"www.eztree-msdn.com ( Laurent Jordi )"




a écrit dans le
message news:
Bon courrage...

Personellement je trouve que l'informatique devient un
art quand en 3


ligne
on parvient à faire ce que d'autres font en 50...

@+

LJ
www.eztree-msdn.com



"Jessy Sempere [MVP]" a
écrit dans le message


de
news:c50gjp$hrp$
Bonjour

Mais pourquoi utilises tu Access dans ce cas ???

Sinon tu peux regarder la fonction MoveSize() pour
redimenssionner



ton formulaire...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit
dans le message



news:
195dc01c41c7f$4b4342a0$
En fait, moi je ne suis pas du tout un développeur
Access.



Ma spécialité, c'est plutot du développement sur
Visualbasic.Net.
je suis ce qu'on appelle un "pisseur de lignes".

Avec Access, on peut faire des formulaires basés sur
des



requetes pour voir les enregistrements ? Tant pis !
Je




n'utilise pas de requete, et je gère tout en code
VB,





avec
mes boutons perso, des textbox indépendants, etc.

Tu vois, la base de données sur laquelle je
travaille





aura
bientôt 10000 lignes de code VB...
En fait, je n'aime pas du tout laisser Access
s'occuper de



tout... Je court-circuite toutes les "fonctions
intrinsèques"...


Pour que mon "formulaire / barre de menu" reste au-
dessus



de tous les autres, j'ai mis la propriété
FenIndépendante



à Oui, et ca marche impeccable. Il ne me manque plus
que



la gestion de sa largeur...



-----Message d'origine-----
Re,

Je pense que tu détourne et complique l'utilisation
d'access pour rien et

donc prend un gros risque. Un bon developpeur
access






ne
code quasiement
rien... Il faut au mximum utiliser les fonctions
Intrinsèques. Pourqoi ne

ferais-tu pas une toute petite fenêtre flottante,
comme




le compagnon office
pour afficher ces éléments ?

Tu pourrais ainsi créer ton menu avec access et
respecter




l'esprit dans
lequel il a été créé. Tu prendrais beaucoup moins
de






risque.

En plus tu risque d'avoir des problèmes pour
essayer






de
faire des menus qui
passeraient au dessus d'un autre formulaire...

@+

LJ
www.eztree-msdn.com
www.ezlogic.mc


"phil" a
écrit






dans
le message de
news:194db01c41c76$19531350$

C'est pour pouvoir insérer des images, et afficher
une




textbox (pour afficher le nom de l'utilisateur en
cours).







-----Message d'origine-----
Salut,

Pourquoi ne personalises-tu pas simplement tes
menus ?






@+

LJ
www.eztree-msdn.com

"phil" a
écrit dans





le message de
news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus personnalisée.
je





sais
qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut de
la





fenêtre...
J'ai cependant un problème : comment puis-je faire
que





mon
formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie barre
de





menu...

Merci de me répondre.


.




.










.




.




.









Avatar
phil
je ne veux que du VB, sinon je m'ennuie...
10000 lignes de code, je trouve que c'est cool...

Mais l'idée était de simplifier le travail de ceux qui
saisissent. Ils ont juste à cliquer sur un bouton pour
poser un jour de congé...

Phil


-----Message d'origine-----
Re

chez moi tu aurais de ces triceps...

C'est vrai que tu n'as pas beaucoup de souplesse avec
Access... néanmoins,

l'utilisation soux d'un formulaire tabulaire continu
aurrait surement pu

faire l'affaire...

Personellement j'aurais gardé Excel pour l'interface IHM
et l'aurais

connecté via DAO à la base Access... A moins qu'excel te
donnes des

boutons...

@+

LJ
www.eztree-msdn.com



"phil" a écrit dans
le message de

news:196c801c41ca4$265b04d0$
en fait, c'est une gestion des congés pour une entreprise.
L'utilisateur bossait sur un document excel, avant. Et il
veut tout avoir sous les yeux.

En colonnes : les dates (4 semaines). En lignes : les
travailleurs (limités à 10 : on peut basculer de l'un à
l'autre avec des bouton haut et bas).
Et dans les cases au milieu, des petites croix pour savoir
si machin est en congé tel jour.
L'utilisateur veut tout voir en même temps pour savoir
quand l'employé M. Machin prend ses congés, et si tout le
monde n'est pas en congé en même temps avant Noël (ce
serait génant) : ils bossent en 24h/24.

Lorsque j'enregistre, je ne crée pas un enregistrement par
employé et par date, mais un enregistrement par jour de
congés pris (par petite croix)...
J'avais pas envie de me creuser la tête à faire un
truc "plus simple". C'était un peu lourd, mais avec un
café, j'ai pu faire l'aspect graphique en une matinée...
Et j'ai mis l'après-midi à faire du code pour enregistrer
et annuler les modifications...

mais j'avoue !!! J'ai surtout improvisé.

phil



-----Message d'origine-----
280 boutons ...

Tu devrais installer Notron System Works pour surveiller
tes ressources

système GDI et UTIL en particulier. Si tu bosses sous
NT4, 2000 ou XP ça ne

devrait pas poser de PB
Sous windows 98 sir tu ouvres ton formulaire alors que
outlook (pas express)

est ouvert tu pourrais avoir de méchantes surprises...

Je pense que quelque soit l'appli que tu développe, si tu
as mis 280 x le

même controle sur un formulaire c'est que ton truc n'est
pas très bien

optimisé.

Un utilisateur ne peux pas saisir simultanément dans 280
Text box...


Dans un cas comme celui ci, j'aurais utilisé une
technique sililaire a

celle utilisée dans les sites Web pour éditer les lignes
d'un formulaire.


Tu crée une ligne de bouton et de text box. A chaque fois
que l'utilisateur

change d'enregistrement, tu recopie les valeurs de
l'enregistrement dans la

ligne d'édition.

Tu n'auras plus qu'1 text box par champ de ta vue, un
bouton Valider 1

bouton Annuler et éventuellement un bouton supprimé.

Je ne connais pas précisément ton appli mais si un mec de
mes équipes fait

ça, je lui fait faire autant de pompes que de contrôle
innutile sur le

formulaire... ;)

@+

LJ
www.eztree-msdn.com


"phil" a écrit dans
le message de

news:14ef701c41c9d$e7aaf340$
je ne me suis pas trop penché la-dessus...
1) L'utilisateur saisit. il met n'importe quoi si il
veut,


je m'en fout.
2) L'utilisateur appuie sur OK. Access vérifie tout d'un
coup et montre ce qui ne va pas...

Mais comment tu ferais pour gérer un tableau de 280
boutons ou 280 textbox, comme j'avais à faire ?

phil



-----Message d'origine-----
Re re re re

Et les règles de validation des champs elles sont faite
pour qui ?

Si tu remplis corectement le champs

Valide Si pour chaque champ de tes tables et que tu
saisis correctement les

messages d'erreur... Un gestion d'erreur suffit... 5 à
10



lignes en fonction
des détails que tu peux afficher...

Tu peux créer un module qui valide tous tes champs et
qui



est
systématiquement appelé en cas d'erreur.

@+

LJ
www.eztree-msdn.com


"phil" a écrit
dans



le message de
news:1697801c41c99$a3629f20$
je suis également d'accord... il faut faire le moins de
lignes possible... mais pour moi, ca ne compte que
lorsque


l'on n'utilise que VB !!!

J'essaye de simplifier tout ce que je peux... mais
lorsqu'il faut vérifier la saisie d'un utilisateur, il
faut bien tester toutes les valeurs : savoir si la
valeur



est nulle, supérieure ou inférieure à telle ou telle
autre


valeur...

et puis quand on gère près de 300 boutons (style
calendrier mais en mieux), on n'a pas le choix, c'est
long !!!
Pour gérer les évènements SurClic de 280 boutons, j'ai
juste eu besoin de quatre lignes par bouton (1 :
initialisation d'un tableau de boutons, 2 : "Sub
buttonX.clic", 3 : "call proc(X)" et 4 : "End Sub"), +
quelques lignes de traitement, communes à tous les
boutons...

J'ai pas encore trouvé mieux... mais si vous avez,
n'hésitez pas !
Je n'ai rien de mieux à faire qu'apprendre...

Phil


-----Message d'origine-----
Entièrement d'accord...
Moins y a de ligne, mieux je me porte, le seul truc par
contre,

c'est que je préfère quelques ligne de code plutôt que
d'utiliser

des macros...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"www.eztree-msdn.com ( Laurent Jordi )"




a écrit dans le
message news:
Bon courrage...

Personellement je trouve que l'informatique devient
un





art quand en 3
ligne
on parvient à faire ce que d'autres font en 50...

@+

LJ
www.eztree-msdn.com



"Jessy Sempere [MVP]" a
écrit dans le message


de
news:c50gjp$hrp$
Bonjour

Mais pourquoi utilises tu Access dans ce cas ???

Sinon tu peux regarder la fonction MoveSize() pour
redimenssionner



ton formulaire...

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a
écrit






dans le message
news:
195dc01c41c7f$4b4342a0$
En fait, moi je ne suis pas du tout un développeur
Access.



Ma spécialité, c'est plutot du développement sur
Visualbasic.Net.
je suis ce qu'on appelle un "pisseur de lignes".

Avec Access, on peut faire des formulaires basés
sur






des
requetes pour voir les enregistrements ? Tant pis !
Je




n'utilise pas de requete, et je gère tout en code
VB,





avec
mes boutons perso, des textbox indépendants, etc.

Tu vois, la base de données sur laquelle je
travaille





aura
bientôt 10000 lignes de code VB...
En fait, je n'aime pas du tout laisser Access
s'occuper de



tout... Je court-circuite toutes les "fonctions
intrinsèques"...


Pour que mon "formulaire / barre de menu" reste au-
dessus



de tous les autres, j'ai mis la propriété
FenIndépendante



à Oui, et ca marche impeccable. Il ne me manque
plus






que
la gestion de sa largeur...



-----Message d'origine-----
Re,

Je pense que tu détourne et complique
l'utilisation







d'access pour rien et
donc prend un gros risque. Un bon developpeur
access






ne
code quasiement
rien... Il faut au mximum utiliser les fonctions
Intrinsèques. Pourqoi ne

ferais-tu pas une toute petite fenêtre flottante,
comme




le compagnon office
pour afficher ces éléments ?

Tu pourrais ainsi créer ton menu avec access et
respecter




l'esprit dans
lequel il a été créé. Tu prendrais beaucoup moins
de






risque.

En plus tu risque d'avoir des problèmes pour
essayer






de
faire des menus qui
passeraient au dessus d'un autre formulaire...

@+

LJ
www.eztree-msdn.com
www.ezlogic.mc


"phil" a
écrit






dans
le message de
news:194db01c41c76$19531350$

C'est pour pouvoir insérer des images, et afficher
une




textbox (pour afficher le nom de l'utilisateur en
cours).







-----Message d'origine-----
Salut,

Pourquoi ne personalises-tu pas simplement tes
menus ?






@+

LJ
www.eztree-msdn.com

"phil" a
écrit dans





le message de
news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus
personnalisée.








je
sais
qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut
de








la
fenêtre...
J'ai cependant un problème : comment puis-je
faire








que
mon
formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie
barre








de
menu...

Merci de me répondre.


.




.










.




.




.




.










Avatar
phil
Bonjour

J'ai créé une barre de menu comme Raymond me l'avait
conseillé. par contre, je n'arrive pas à créer de label.
Je fais ca :
Set CBBouton = .Controls.Add(msoControlLabel)
selon la technique décrite par Raymond...

Et à la compilation, j'ai ce message d'erreur :
argument ou appel de procédure incorrect

Où est mon erreur ?

Merci


-----Message d'origine-----
Bonjour

Les boutons dont tu parles ne font pas partie de la barre
de menu

d'access, mais de la fenêtre Access...

Si tu veux les désavtiver, le code qui suit devrait te
convenir...


*************************************************
Public Declare Function GetSystemMenu Lib "user32" _
(ByVal hwnd As Long, ByVal bRevert As Long) As Long

Public Declare Function GetMenuItemCount Lib "user32" _
(ByVal hMenu As Long) As Long

Public Declare Function RemoveMenu Lib "user32" (ByVal
hMenu As Long, _

ByVal nPosition As Long, ByVal wFlags As Long) As Long

Public Declare Function DrawMenuBar Lib "user32" (ByVal
hwnd As Long) As

Long

Global Const MF_BYPOSITION = &H400
Global Const MF_REMOVE = &H1000

Public Function MenuAccessInactif(Optional MenuItem)
'** MenuItem
'** 6 : Fermer
'** 5 : Barre de séparation
'** 4 : Agrandir
'** 3 : Reduire
'** 2 : Taille
'** 1 : Déplacer
'** 0 : Restaurer
'On Error Resume Next
Dim hMenu As Long
Dim menuItemCount As Long
Dim i As Integer
hMenu = GetSystemMenu(Application.hWndAccessApp, 0)
If hMenu Then
menuItemCount = GetMenuItemCount(hMenu)
If IsMissing(MenuItem) = True Then
For i = menuItemCount - 1 To 0 Step -1
Call RemoveMenu(hMenu, i, MF_REMOVE Or
MF_BYPOSITION)

Next
Else
Call RemoveMenu(hMenu, MenuItem, MF_REMOVE Or
MF_BYPOSITION)

End If
Call DrawMenuBar(Application.hWndAccessApp)
End If
End Function
*************************************************
@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"phil" a écrit dans
le message news:

195f901c41c82$a0fc44f0$
merci je pensais pas qu'on pouvait mettre de zone de liste
dans une barre de menus...
Je pense que je vais peut-être revoir mon menu...
Ce qui me genait le plus, c'est que je ne savais pas qu'on
pouvait gérer la barre de menu et ses évènements avec du
code VB...

Mais au fait, comment faire pour masquer la barre de menu
principale, celle qui a les trois boutons réduire,
restaurer et fermer? Je voudrais ces trois boutons dans ma
barre de menu perso...

Merci
Phil


-----Message d'origine-----
Bonjour.

Tu trouveras un exemple de barre de menu personnelle et
même une base

exemple d'utilisation avec combobox dans le menu. Il me
semble plus simple

de passer par cette méthode que par un formulaire en
fenêtre indépendante.

http://access.seneque.free.fr/barre_de_menus.htm

--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"phil" a écrit dans
le message de

news:1956b01c41c74$79bb5240$
Je voulais faire une barre de menus personnalisée. je
sais


qu'il est possible de le faire, mais j'ai préféré
réaliser


un formulaire indépendant, qui se place en haut de la
fenêtre...
J'ai cependant un problème : comment puis-je faire que
mon


formulaire ait la largeur de la fenêtre ?
Je voudrais faire qu'il soit comme une vraie barre de
menu...

Merci de me répondre.


.




.




Avatar
Raymond [mvp]
Bonjour.

as-tu bien coché la référence à microsoft office ?
msoControlLabel est un argument ms office.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"phil" a écrit dans le message de
news:19e6e01c41d48$a24295a0$

Bonjour

J'ai créé une barre de menu comme Raymond me l'avait
conseillé. par contre, je n'arrive pas à créer de label.
Je fais ca :
Set CBBouton = .Controls.Add(msoControlLabel)
selon la technique décrite par Raymond...

Et à la compilation, j'ai ce message d'erreur :
argument ou appel de procédure incorrect

Où est mon erreur ?

Merci
Avatar
phil
Comme tu l'as mis sur ton site, il faut MS09.dll
je l'ai récupéré sur un runtime access que j'ai trouvé...

Et je l'ai coché dans références, et j'ai ainsi pu
utiliser les combobox, les sous-menu, les boutons, mais
pas grand chose d'autre. Les labels ne fonctionnent pas,
mais beaucoup d'autres aussi.


Il faut cocher une référence supplémentaire ?
Merci

Phil




-----Message d'origine-----
Bonjour.

as-tu bien coché la référence à microsoft office ?
msoControlLabel est un argument ms office.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"phil" a écrit dans
le message de

news:19e6e01c41d48$a24295a0$

Bonjour

J'ai créé une barre de menu comme Raymond me l'avait
conseillé. par contre, je n'arrive pas à créer de label.
Je fais ca :
Set CBBouton = .Controls.Add(msoControlLabel)
selon la technique décrite par Raymond...

Et à la compilation, j'ai ce message d'erreur :
argument ou appel de procédure incorrect

Où est mon erreur ?

Merci



.



Avatar
Raymond [mvp]
il ne faut pas autre chose, non.
j'ai vérifié avec les différentes versions le msocontrollabel est bien
reconnu partout.
il doit y avoir une ch'tite erreur à quelque part dans tes déclarations car
c'est à la compilation que tu as l'erreur.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"phil" a écrit dans le message de
news:19f5801c41d61$a6db2730$

Comme tu l'as mis sur ton site, il faut MS09.dll
je l'ai récupéré sur un runtime access que j'ai trouvé...

Et je l'ai coché dans références, et j'ai ainsi pu
utiliser les combobox, les sous-menu, les boutons, mais
pas grand chose d'autre. Les labels ne fonctionnent pas,
mais beaucoup d'autres aussi.


Il faut cocher une référence supplémentaire ?
Merci

Phil
Avatar
phil
dans un nouveau module :

Dim CB As CommandBar
Dim CBBouton As CommandBarControl
Const CB_Nom = "Nom"

Sub CreeMenu()
Set CB = CommandBars.Add(CB_Nom)
Set CBBouton = CB.Controls.Add(msoControlLabel)
CBBouton.Caption = "hello"
CBBouton.Enabled = True
End Sub


uniquement ces lignes: réponse à la compilation :
argument ou appel de procédure incorrect

je ne comprends pas ce qui ne va pas...

phil

-----Message d'origine-----
il ne faut pas autre chose, non.
j'ai vérifié avec les différentes versions le
msocontrollabel est bien

reconnu partout.
il doit y avoir une ch'tite erreur à quelque part dans
tes déclarations car

c'est à la compilation que tu as l'erreur.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"phil" a écrit dans
le message de

news:19f5801c41d61$a6db2730$

Comme tu l'as mis sur ton site, il faut MS09.dll
je l'ai récupéré sur un runtime access que j'ai trouvé...

Et je l'ai coché dans références, et j'ai ainsi pu
utiliser les combobox, les sous-menu, les boutons, mais
pas grand chose d'autre. Les labels ne fonctionnent pas,
mais beaucoup d'autres aussi.


Il faut cocher une référence supplémentaire ?
Merci

Phil



.



1 2 3 4