Runtime : Bouton Aperçu impression pour un Tableau/Graphique croisé dynamique

[Matthieu L]

Bonjour,

afin de donner accès à quelques fonctions de base aux utilisateurs de mon application dans le Runtime 2003, j'ai donc créé une barre d'outils personnalisée qui s'affiche très correctement quand j'ouvre l'application dans le Runtime.

Cette barre d'outils comprend les boutons "Aperçu avant impression"... mais dès que j'affiche un tableau croisé dynamique ou un graphique croisé dynamique, le bouton disparait alors qu'il fonctionne parfaitement pour les tables, les requetes, les formulaires et les états.

J'ai le même problème avec le bouton "Mise en page"

Je n'ai pas ce problème quand j'ouvre l'application dans Access 2003.

C'est extrêmement frustant.

Comment faire pour que ces deux boutons soient maintenus dans ma barre d'outil lorsqu'on utilise le runtime ?

Merci pour vos réponses.

[argyronet]

Bonjour,

Certaines fonctions sont désactivées avec le Runtime...

Pour te mettre dans la même situation avec ton poste de dev et faire tous les essais contraignant qui s'imposent, créé un raccourci sur ton bureau avec la syntaxe :

Code :

1
2
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" _
"C:\Program Files\TonDossier\TonAppli.mdb" /runtime

Argy

[Matthieu L]

Merci pour cette précision... mais c'est exactement cette méthode que j'utilise déjà pour tester mon application en runtime.

Mais est-ce que cela veut dire qu'on ne peut pas afficher ces fonctions dans le runtime, même en utilisant une barre d'outils personnalisée ?

Merci d'avance pour votre aide !

Matthieu

[argyronet]

Dans une application finie, un utilisateur n'est pas censé effectuer de mise en page. Cela doit être prévu et figé par le développeur.

Je ne vois pas l'intérêt de laisser de telles fonction pour un utlisateur à moins que tu en aies une bonne à me soumettre.

Argy

[isa911]

Tu ne laisses donc pas les utilisateurs faire de tri, de classement ou d'impression de données sous forme de liste qui peut etre mis en page en paysage ou portrait, selon ce qu'ils veulent comme données ?
Chez nous, ils travaillent beaucoup avec des listes comme ca, et du coup, je dois me refaire toutes les barres, mais bien sur les fonctions accessibles des "Personnaliser" ne sont pas tout a fait les meme, bonjour le boulot !!!

Isa qui n'a pas fini de se retapper les barres ...

[argyronet]

Isa, ça n'a rien à voir...
De toute façon, mettre en oeuvre une CommandBar est loin d'être sorcier.
Les phénomènes de tris (je parle pour mes propres projets) et préférences sont systématiquement prévus et adaptés en conséquence de ce qui doit être imprimé.
Dans un autre point de vue et par rapport au CC, je propose et le client valide.

Ce que je veux dire, c'est que lorque l'on fait le choix de mettre à disposition le Runtime, cela implique qu'il faut oublier Access et ses fonctionnalités de conception.

En plus, ça ne sert à rien de se fâcher...
Ca ne changera rien.

Argy

[isa911]

Oui, Désolé, je me suis un peu emportée ...

En fait, tout le dilemme, c'est que la base a été developpée au depart en 97 et chacun avait un version complete d'Access sur son poste, et puis en passant en 2003, on a pensé que c'etait inutile de garder la version complete, que le Runtime suffirait et puis finalement, il y a quelques utilisateurs qui veulent avoir la meme facon de travailler qu'avec Access : pouvoir creer des requetes soit meme, modifier certaines fonctions sans passer par des parametres etc ... de la bidouille quoi ...

[argyronet]

Coté requêtes, personnellement, j'avais mis en place un truc comme ça :



Ca marchait bien et c'était suffisant.
Plus tard, j'avais mis en place un interpréteur littérale pour les novices en SQL.
Bref, ça solutionnait la problématique du mode conception du Runtime...

Coté fonction, rien ne t'empêche de créer les tiennes et de les proposer à bon escient à partir de telle ou telle ciconstance.


Argy