[Calc] controle de table pour afficher données de feuille

[jlf]

bonjour

je voudrais afficher sur une feuille Calc les données d'une autre feuille en conservant la forme tabulaire, la liste à afficher étant variable en fonction de la cellule activée par l'user

la zone de liste permet de le faire mais sur une seule colonne, il faut bricoler les longueurs des items de chaque ligne pour garder un vague aspect tabulaire, ce n'est pas idéal et même inutilisable dans certains cas
le contrôle de table semblait mieux adapté

j'ai vu ici (2d sujet de la page) :
https://forum.openoffice.org/fr/forum/v ... 15&t=11928
un moyen de créer un contrôle de table à la volée sur un dialogue et d'y insérer des données

mais j'ai l'impression que le cdt créé (UnoControlGridModel) n'est pas exactement celui disponible sur la barre d'outils des contrôles, en tous cas je ne parviens pas avec xRay à retrouver la hiérarchie permettant d'arriver aux fonctions nécessaires dans mon cas, notamment addRow et removeAllRows

savez vous si j'ai raté quelque chose, ou si le cdt de l'EDI est exclusivement réservé à une source BDD au contraire du gridModel ?

je vous remercie de votre aide

[Dude]

Salut,

afficher sur une feuille Calc les données d'une autre feuille

Pour que ce contrôle fonctionne, il faut s'appuyer sur une connexion à une source via un ODB.

[jlf]

Pour que ce contrôle fonctionne, il faut s'appuyer sur une connexion à une source via un ODB.

OK merci
dommage, car les données à mettre dans une fenêtre de consultation viennent déjà d'un odb (firebird embarqué)

mais je suis obligé de couper la connexion pour contourner le pbm multi-utilisateurs, calc ne se branche que pour recharger les données et updater, une ou deux fois par jour max
donc je stocke dans une feuille cachée du classeur ...

la zone de liste ne convient pas bien bien du fait de la largeur très variable des items, de la nécessité à afficher au moins le début de chaque colonne pour éviter des clicks multiples et avec un espace dispo pour la fenêtre d'affichage dans la zone figée assez limité

le contrôle de table semblait idéal

je pourrais peut être utiliser un dialogue non modal et la listBox dynamique que tu proposes dans la page citée
mais la garder au top mange beaucoup de ressources si j'ai bien vu les autres posts sur le sujet, il faut une boucle loop permanente avec un wait plus un listener

il n'y a vraiment pas d'autre moyen d'afficher des données feuilles cachées dans un cadre multicolonnes avec ascenseurs et actualisées avec une simple gestion d'évènement sur la feuille visible ?

[Dude]

dommage, car les données à mettre dans une fenêtre de consultation viennent déjà d'un odb

Pourquoi dire le contraire à ton 1er message ?

les données d'une autre feuille

Une feuille est un élément du tableur, pour Base, il s'agit d'une table.
Si les données sont dans une table, tu crées un formulaire dans l'ODB.

[jlf]

Pourquoi dire le contraire à ton 1er message ?

tu lis trop vite, ou je m'exprime mal, ou les deux

je redis autrement :
les données sont dans un odb utilisé par tout le monde, donc pas de connexion permanente possibles entre les classeurs utilsés comme interface et la base

les utilisateurs ne se connectent qu'une ou deux fois par jour rapidement, le temps de charger et d'updater
=>
je recopie les données liées dans une feuille cachée du classeur interface, et c'est elles que je veux fenêtrer dans la feuille visible

pour utiliser le contrôle de table je pourrais effectivement, comme ta remarque me fait penser, charger le matin dans un odb spécifique à l'utilisateur au lieu de le faire dans un classeur
mais du coup ça ferait 2 fichiers à distribuer, ce qui poserait d'autres pbm dans le contexte et je crois que je préfère encore la zone de liste avec de nombreux clicks de défilement droite et gauche ...

je reviens sur le contrôle de table : tu as nommé comme cela le listBox que tu crées à la volée dans la page citée à mon 1er post
si ce n'est pas les mêmes objets ne serait il pas mieux d'en changer le nom sur ta page car je me suis lancé sur cette voie par cette homonymie ?

certes tu y ajoutes un petit § sur l'indisponibilité dans l'EDI, mais avec le même nom qu'un objet existant aujourd'hui on suppose que c'était une remarque relative à une version précédente

[Dude]

je reviens sur le contrôle de table : tu as nommé comme cela le listBox que tu crées à la volée dans la page citée à mon 1er post

Ce contrôle est fait pour fonctionner dans un dialogue. Pas sur un formulaire.

[jlf]

Ce contrôle est fait pour fonctionner dans un dialogue. Pas sur un formulaire.

c'est sûr qu'après quelques heures d'arrachage de cheveux j'ai fini par m'en rendre compte

sûr aussi que je ne suis pas spécialement doué, mais je ne suis sans doute pas le seul et une petite précision suffirait peut-être à sauver de nombreuses crinières

[Dude]

et une petite précision suffirait

Qu'est ce que tu ne comprends pas dans le titre du suprême ?

Capture.jpg

Maintenant, comme je l'ai dit plus haut, le contrôle table fonctionne dans un formulaire s'il y a une source connectée.
Donc, je ne vois pas l'intérêt de recopier.

FormTableBiblio.ods

[jlf]

Qu'est ce que tu ne comprends pas dans le titre du suprême ?

juste ça :

2021-05-03 17_45_58-Window.png

le nom que tu utilises est le même que celui de l'objet ayant les mêmes fonctions sur la barre d'outil, laquelle par ailleurs est aussi une sorte d'IDE (au sens large) pour les non ooOlders à qui est destiné en principe ce forum

listBox, ou un truc équivalent, eut été manifestement moins ambigu

bon, tu soutiens que la confusion n'est pas possible, OK, si c'est ton avis définitif pas de soucis
je le signalais simplement pour épargner a d'autres prétendants au cdt cette source de confusion (elle m'est arrivée donc c'est un fait, pas une réalité alternative)
mais au fond c'est bien toujours l'espoir qui fait vivre donc OK aussi

Maintenant, comme je l'ai dit plus haut, le contrôle table fonctionne dans un formulaire s'il y a une source connectée

si ce n'est pas un vrai dialogue de sourds ça y ressemble beaucoup
en tous cas l'un de nous deux ne comprend pas l'autre

je disais :

les données sont dans un odb utilisé par tout le monde, donc pas de connexion permanente possibles entre les classeurs utilsés comme interface et la base

si je mets l'odb base en source d'un formulaire d'un classeur, les autres classeurs des autres utilisateurs vont avoir du mal à y accéder en même temps, non ?
donc chacun ne se connecte à l'odb qu'une ou deux fois par jour, en gros pour charger ses données le matin et ajouter ses modifs le soir, entre les deux il est tout seul avec son classeur, sans odb

[Dude]

si je mets l'odb base en source d'un formulaire d'un classeur, les autres classeurs des autres utilisateurs vont avoir du mal à y accéder en même temps, non ?

Si tu cherches à faire du client/serveur, il ne faut pas utiliser un ODB avec une base embarquée mais un SGBD externe.
Base en mode natif est fait pour fonctionner en mode mono-utilisateur.
Une connexion à un classeur ne se fera qu'en lecture seule, ce qui rend impossible toute mise à jour sur le contrôle.

[jlf]

Si tu cherches à faire du client/serveur, il ne faut pas utiliser un ODB avec une base embarquée mais un SGBD externe.

oui un SGBD externe serait l'idéal, bien d'accord, et avec nous deux sans doute le reste du monde

mais comme disait (plus ou moins) Alain l'idéal a beaucoup moins de pouvoirs que le pouvoir n'a d'idéal

dans mon cas ledit pouvoir réserve tout ce qui est SGBD à des grosses applis nationales, dont malheureusement les crédits de développement sont orientés loin de nous pour longtemps

bref, tout ce que j'ai le droit de mettre sur les réseaux locaux c'est, je te le donne en mille, ... des fichiers Libo !
la moindre dll, le moindre exe, sont strictly forbidden

Base en mode natif est fait pour fonctionner en mode mono-utilisateur.

mon petit cerveau est également mono-tache, pourtant ce matin j'ai réussi à repasser mes chaussettes, aller au boulot, te répondre, et je te dis pas tout
disons que j'essaie de prouver que Libo peut faire aussi bien que moi


bref pour revenir à un équivalent de controle de table affichant dynamiquement des données de feuilles, tu confirmes l'impossibilité en dehors de la mono-colonaire zone de liste ?

[Dude]

Fais l'essai par toi-même, tu crées un ODB rattaché à un classeur. Tu verras que la :

connexion à un classeur ne se fera qu'en lecture seule, ce qui rend impossible toute mise à jour sur le contrôle

[jlf]

Fais l'essai par toi-même, tu crées un ODB rattaché à un classeur [...]

aie, on retombe dans une conversation autistique
ma question depuis 10 posts n'a pas changé, classeurs sans ODB, ces derniers n'ayant été évoqués que pour expliquer le contexte
la dernière tentative de formulation :

bref pour revenir à un équivalent de controle de table affichant dynamiquement des données de feuilles, tu confirmes l'impossibilité en dehors de la mono-colonaire zone de liste ?

[Dude]

Quand tu poses un contrôle sur une feuille, il est attaché à un formulaire.
Formulaire qui est relié à une table ou une requête et donc à un ODB.

no_problemo.png

[jlf]

Quand tu poses un contrôle sur une feuille, il est attaché à un formulaire.
Formulaire qui est relié à une table ou une requête et donc à un ODB.

ton raisonnement est obscur car tu sais pertinemment qu'on peut mettre plein de contrôles sur un formulaire sans lier obligatoirement avec un odb
par ex une zone de liste
il suffit que le contrôle ait un ancêtre muni de fonctions d'accès aux feuilles, non publiées et plus ou moins cachées dans la hiérarchie

mais tout ça nous éloigne de la question initiale ...

les lecteurs doivent bien s'amuser, on est presque kafkaïens, le style en moins bien sûr

[Dude]

Un GridControl n'est pas un contrôle ordinaire. Il s'appuie sur une connexion à une source de données (DataForm).
https://www.openoffice.org/api/docs/com ... ntrol.html

il suffit que le contrôle ait un ancêtre muni de fonctions d'accès aux feuilles, non publiées et plus ou moins cachées dans la hiérarchie

Non prévu par l'API
Donc demande d'amélioration à ouvrir auprès des développeurs.
Si tu le fais, n'oublies pas de mettre la balise [Issue] et d'en donner le n° du rapport ouvert.

[jlf]

Un GridControl n'est pas un contrôle ordinaire. Il s'appuie sur une connexion à une source de données

oui, tu me l'a dit dès ta première réponse, je l'avais noté et t'avais remercié

c'est dans la suite qu'on a tourné en rond :
j'ai commis l'erreur de te dire pourquoi je pouvais pas passer par un odb avec un texte manifestement trop long que t'as pas eu envie de lire, et de te demander s'il n'y avait pas à ta connaissance un contournement, ou un "simili" cdt

du coup on a consciencieusement tourné chacun dans nos cages respectives
bon, je saurai jamais je suppose, pardon d'avoir monopolisé ton temps pour rien et merci pour ta première réponse

[Dude]

et de te demander s'il n'y avait pas à ta connaissance un contournement, ou un "simili" cdt

Je me répète encore :

Non prévu par l'API

Maintenant, il y a toujours la possibilité du contrôle dans un dialogue ou encore de créer un ODB à la volée.

bon, je saurai jamais je suppose

Et de conclure :

demande d'amélioration à ouvrir auprès des développeurs

Si tu ne fais rien, tu mets [Résolu] afin de clore ce fil insoluble.