Discussion :

[harpyopsis]

Bonjour à tous !

Je suis en train de convertir une *.mdb de 2003 vers *.accmdb 2007 puis 2016.

Mes utilisateurs sont allergiques à l’encombrant et disgracieux Ribbon (et moi à la gestion de USysRibbons en XML !)

J’avais créé sous 2003 une CommandBar de 13 contrôles, et +/- 60 Items (Text Only always), activés ou désactivés selon le niveau de permission de chaque utilisateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
DoCmd.ShowToolBar "Menu Bar", acToolbarYes
 
Dim MyCmdBar As CommandBar, TargetCBItem As CommandBarControl
    Set MyCmdBar = CommandBars("VetoBar")
MyCmdBar.Controls(11).Enabled = True   		‘Comptabilité 
Set TargetCBItem = CommandBars.FindControl(Tag:="ProductsBase")
    If Not TargetCBItem Is Nothing Then TargetCBItem.Enabled = True

Sobre et peu encombrante, cette CommandBar a donné entière satisfaction durant de longues années.

J’ai fini par découvrir «Classic Menu for Office» sur AddinTools, qui importe la «Menu Bar» + les ToolBox originales de 2003 dans un onglet du Ribbon 2007, appelé «Menus».

En référençant OFFICE\MSO.dll, j’ai ensuite importé ma fidèle «VetoBar» de 13 menus. Et elle fonctionne parfaitement dans 2007 !

Le hic pour lequel je m’adresse à vous, c’est que cette CommandBar se retrouve dans un nouvel onglet du Ribbon, automatiquement appelé Add-Ins. Et le Ribbon impose encore une fois toute son inutile hauteur et ses onglets...

Bref j’ai ceci



Au lieu d’avoir ceci



Quelqu’un aurait-il une idée pour minimiser le haut de la fenêtre Access 2007, étant donné que les utilisateurs n’ont aucun besoin du contenu du Ribbon ???? <ribbon startFromScratch="True"> ???

Merci d'avance !

[james68]

Salut , je suis du même avis que toi... le ribbon est infect.
une des raisons pour lesquelles je suis encore sous 2000.
De plus au vu du peu de réponse a ta question,
j'en deduit qu'il faut faire avec ce satané Ruban...
bon courage....
++

[harpyopsis]

Bonjour James et un très grand merci pour ton message ! On se sent tout à coup moins seul dans son coin !... J'ai eu quelques réponses sur access-grogrammers.co.uk, qui vont toutes aussi dans le même sens.

En bref, on n'a jamais fait mieux que la vraie CommandBar de 2000 ! Avec ses menus et sous-menus déroulants. Intuitif, mignon, rapide, encombrement minimal, reposant à la vue, extensible à volonté. Et surtout facile à programmer ! Puisque toutes les propriétés des Items et toutes les configurations et actions possibles sont condensées dans de petites boîtes de dialogue bien pratiques, et que tout peut se programmer à runtime en VB6.

Tout le monde s'accorde donc en effet pour détester le Ruban. Effectivement, l'importation d'une vraie CommandBar 2003 dans 2007 est possible. Mais on n'obtient jamais le même résultat, car on est toujours embêté par le Ruban qui revient toujours s'imposer avec ses tabulations et sa hauteur fixe, bien encombrant et très laid.

La seule chose à faire pour mon cas a été de créer un Ruban vide (fromscratch = "True"), d'y créer des onglets correspondant aux 13 menus de ma barre de commandes d'origine, et de remplir ce Ruban de boutons rassemblés en groupes correspondants aux sous-menus initiaux.

Ne pas oublier de faire Minimize automatiquement.

Pas d'autre solution ! Mais si les utilisateurs s'habituent, ce n'est pas plus mal. L'esthétique n'est pas terrible, l'alignement vertical est complètement absent, mais on s'y fait.

La programmation est vraiment usante !... Une vraie perte de temps (compter deux jours pleins si c'est un premier essai). Tu dois créer d'abord une Table USysRibbons, dont un champ Mémo servira à héberger le code xml de chaque Ruban que tu veux créer. Puis tu crées un formulaire frmUSysRibbons qui te permettra d'éditer tout cela. Utiliser aussi un éditeur xml extérieur genre NotePad++, c'est plus propre. Mais Diantre que ce langage xml est long, lourd et laid !

Ce n'est pas tout : tu dois maintenant créer un module normal pour héberger les fonctions d'ouverture des formulaires de ton projet Access et de les appeler à partir du code xml OnAction des Boutons. Chaque procédure est suivie de (control as IRibbonControl) et non de (). Utilise le Docmd.OpenForm, surtout si tu as besoin de OpenArgs.

Tu commandes l'utilisation de tel ou tel Ruban à l'ouverture du projet, et je ne sais pas encore si l'on peut changer de Ruban at runtime.

Voilà où j'en suis en ce moment. Je n'ai pas encore réussi à obtenir toute la collection des propriétés des contrôles dans le Ruban (les Boutons) surtout dans l'espoir (assez mince) de pouvoir les positionner autrement qu'en rang d'oignon.

Comme j'ai plusieurs niveaux de permission pour les utilisateurs, je dois maintenant pouvoir activer /désactiver certains boutons, et je ne sais pas encore si ça va se faire en vba comme d'hab, ou bien en xml avec toute une collection de Rubans dédiés...

Un vrai-bor-del !

Comme tu vois, il faut vraiment vouloir passer à 2016 pour se lancer dans la programmation du Ruban !

Si tu veux, je te ferai passer du code.

Amitiés, restons en contact !

phil

[micniv]

bonjour,

As-tu parcouru le tuto g'Arkham46 https://arkham46.developpez.com/arti...sistant-ruban/ ?
En principe, c'est salutaire.

CDLT

[harpyopsis]

Bonsoir ! Non pas encore, j'y vais de ce pas ! Merci !

EDIT

Voilà un travail très impressionnant ! je l'installe immédiatement !

[james68]

Merci pour ta réponse, harpyopsis.
je reviendrais vers toi le cas échéant...
mais pour l'instant je n'ai pas franchi le cap du passage a ce ruban...lol
Bonne journée a toi
++

[stigma]

Je pensais être un des seuls à m'arracher le peu de cheveux qui me restent avec ce foutu ruban de b....l de m....e
Je veux juste migrer une appli 2003 vers 2007 pour des problèmes de runtime maintenant introuvable avec Access 2003.