Discussion :

[Depite]

Bonjour,

Je suis passé directement d'access 2003 à Access 2010 depuis 3 ans et ai choisi de suivre la philosophie de Microsoft en utilisant les rubans en lieu et place des menus proposés dans les version antérieures à 2007.

Néanmoins, je comprends toujours mal l'intérêt de ces rubans par opposition aux anciens menus. En effet leur création est lourde et leur exploitation compliquée (me semble-t-il).

Autre inconvénient particulièrement gènant des rubans c'est leur chargement unique en mémoire, je m'explique:
Lors du démarrage de l'application (mon projet) j'affecte une variable globale représentant mon objet ruban et construits les différents contrôles qu'il comporte en affectant les propriétés de visibilité et d'accessibilité.

Mais lorsque je suis amené a arrêter l'exécution de mon projet (en mode de conception bien sur) cette variable se trouve de fait supprimée et il est ensuite impossible - à ma connaissance - de lui réaffecter l'objet ruban qui, lui, est construit et ne peut pas être reconstruit, ce qui nécessite de fermer Access pour le réouvrir et recommencer avec tout ce que celà implique : perte des points d'arrêt, des signets et des espoions entre autre.

Quant à revenir aux anciens menus - dans le cadre d'un nouveau projet - j'y ai bien songé mais je ne vois pas dans la version 2010 (projets ADP) comment créer et entretenir des barres de menus personnalisées dans l'IDE même si on peut toujours fair féférence aux objets de gestion de menus d'Office.

Je ne doute pas que les experts du forum sauront éclairer ma lanterne et m'éviter une régression insuportable.

[naphta]

Bonjour,

C'est vrai moi aussi j'ai trouvé la gestion des ruban très fastidieuse et complexe au niveau de la mise au point. J'ai failli devenir zinzin parfois. Le truc du redémarrage de l'appli ça rend fou.

Par contre au niveau du résultat j'ai trouvé que le principal avantage est du point de vue ergonomique.
Il faut un ruban général et un ruban par formulaire et état.
On se retrouve avec des formulaires simples et lisibles.
Personnellement sur la plus grande partie de mes formulaires il reste juste un bouton fermer (en cas de plantage de l'appli.)

Heureusement, il y a un allemand sur le net qui permet de faire un apprentissage rapide des rubans, Gunter Avenius.

a+

[Dolphy35]

Bonjour,

Les Rubans on été mis en place avec Access 2007 et ont marqués un tournant ds la suite Office. L'utilisation rebute les personnes au premier abords mais une fois pris en main c'est un plaisir. A l'époque MS avait fait une étude qui a donner comme résultats que les fonctionnalités des uite Office n'était pas toutes utilisées du fait de la complexité de les retrouvées (menu, d'un sous menu d'un menu, etc.). La mise en place de Ruban permet de données de accessibilité aux fonctions. Perso je trouve l'utilisation très pratique.

J'ai décidé de déployer ce principe à mes applications afin de leur donner un côté plus lisible. Une fois compris le principe je trouve la mise en place simple et rapide avec 2010 on peut même personnaliser le Backstage.

Par contre j'utilise l'outil d'Arkham46, je ne peux plus m'en séparer. Celui-ci s'intègre à Access (complément) et permet de faire des modifications rapides.
http://arkham46.developpez.com/artic...sistant-ruban/

ensuite pour comprendre le fonctionnement des Rubans voici un peu de lecture :
http://warin.developpez.com/access/ruban/

images dans les Rubans:
http://arkham46.developpez.com/artic...s/rubanimages/

Pour revenir à des menus 2003:
http://jdgayot.developpez.com/tutori...s-access-2007/

Pour personnaliser le Backstage:
http://dolphy35.developpez.com/artic...010/backstage/

pour Excel:
http://silkyroad.developpez.com/excel/ruban/

@+

[Depite]

Bonjour,

Merci Dolphy35 pour tous ces liens fort intéressants et que j'avais déjà, pour certains, consulté avec grand intérêt.

Je ne conteste pas l'intérêt ergonomique des rubans, les machines d'aujourd'hui sont surpuissantes et ont parfois un proccesseur qui tourne en rond à ne pas faire grand chose alors autant l'occuper à dessiner de belles images colorées.

C'est donc joli mais...

• sur des applications de gestion avec de nombreux écrans de consultation ou de saisie de type tableau le ruban consomme une place beaucoup plus importante qu'une barre de menus et une barre d'outils - et ne viens pas me dire qu'on peut réduire le ruban : và en parler aux utilisateurs...
• la création et la maintenance des rubans, bien que rendue plus aisée par l'outil proposé par Arkham46 - que je remercie vivement ici - ne tient pas la comparaison avec la facilité de création et de personnalisation d'une barre de menus ou d'une barre d'outils des versions antérieures à 2007

D'autant plus que sur ces anciens modèles il était possible de tester instantanément les commandes mises en place et ce sans limite et sans avoir à fermer et réouvrir l'application perdant au passage tous les points d'arrêt et tous les signets!

Et c'est sans compter avec la lourdeur de gestion des événements issus des contrôles des rubans.
Je ne parle pas de l'affectation directe d'une fonction spécifique au traitement de chaque événement mais de la centralisation des ces traitements fondée sur l'exploitation de leurs identifiants.

Tout ça ne m'a pas pas empêché de créer un système de menu utilisant uniquement les rubans; conséquence d'une volonté, à la création du projet, d'intégrer au mieux les nouvelles fonctionnalités en vue d'assurer la pérennité du programme.

En résumé je déplore 3 absences majeures au niveau de l'environnement de développement :

1. L'absence de possibilité de créer des rubans personnalisés et nommés, intégrés à la définition de la base de données (mais pas enregistrés dans une table ce qui est impossible dans un projet ADP)
2. L'absence de possibilité de créer dans l'interface un contrôle libre associé à l'exécution d'une fonction VBA et non d'une MACRO
3. Le fait que le ruban ne soit associable à une variable qu'au moment de sa création et qu'il soit impossible de le recréer sans décharger le projet au préalable.

Tout ceci ne m'empêche pas d'utiliser Access de préférence à tous les autres outils de développement pour la réalisation des applications de gestion.

[Ludovic.boudi]

Bonjour,

Merci Dolphy35 pour tous ces liens fort intéressants et que j'avais déjà, pour certains, consulté avec grand intérêt.

Je ne conteste pas l'intérêt ergonomique des rubans, les machines d'aujourd'hui sont surpuissantes et ont parfois un proccesseur qui tourne en rond à ne pas faire grand chose alors autant l'occuper à dessiner de belles images colorées.

C'est donc joli mais...

• sur des applications de gestion avec de nombreux écrans de consultation ou de saisie de type tableau le ruban consomme une place beaucoup plus importante qu'une barre de menus et une barre d'outils - et ne viens pas me dire qu'on peut réduire le ruban : và en parler aux utilisateurs...
• la création et la maintenance des rubans, bien que rendue plus aisée par l'outil proposé par Arkham46 - que je remercie vivement ici - ne tient pas la comparaison avec la facilité de création et de personnalisation d'une barre de menus ou d'une barre d'outils des versions antérieures à 2007

D'autant plus que sur ces anciens modèles il était possible de tester instantanément les commandes mises en place et ce sans limite et sans avoir à fermer et réouvrir l'application perdant au passage tous les points d'arrêt et tous les signets!

Et c'est sans compter avec la lourdeur de gestion des événements issus des contrôles des rubans.
Je ne parle pas de l'affectation directe d'une fonction spécifique au traitement de chaque événement mais de la centralisation des ces traitements fondée sur l'exploitation de leurs identifiants.

Tout ça ne m'a pas pas empêché de créer un système de menu utilisant uniquement les rubans; conséquence d'une volonté, à la création du projet, d'intégrer au mieux les nouvelles fonctionnalités en vue d'assurer la pérennité du programme.

En résumé je déplore 3 absences majeures au niveau de l'environnement de développement :

1. L'absence de possibilité de créer des rubans personnalisés et nommés, intégrés à la définition de la base de données (mais pas enregistrés dans une table ce qui est impossible dans un projet ADP)
2. L'absence de possibilité de créer dans l'interface un contrôle libre associé à l'exécution d'une fonction VBA et non d'une MACRO
3. Le fait que le ruban ne soit associable à une variable qu'au moment de sa création et qu'il soit impossible de le recréer sans décharger le projet au préalable.

Tout ceci ne m'empêche pas d'utiliser Access de préférence à tous les autres outils de développement pour la réalisation des applications de gestion.

Bien que je n'ai pas complétement vérifié tous les points que tu site, il me semble que nombre d'entre eux sont réglés dans la version 2013.

Version majeure car elle apporte la capacité de générer des catalogues de services sharepoint pour les sites d'équipes (WebApp pour Sharepoint+SQL server 2012).

Donc aujourd'hui il ne luis manquerait plus que la capacité de générer des applications autonomes multi-plateformes pour en faire le meilleur outil de conception rapide.