NSScrollView et NSTableView
Hello,
Il y a un truc qui m'échappe avec NSTableView: la vue quand est inclue dans une NSScrollView dans IB, alors que dans les faits la scrollview semble subordonnée à la tableview, dans la mesure où les entêtes des colonnes ne bougent pas quand on bouge les scrollers, alors que si la table aurait été "bêtement" subordonnée à la scrollview, les entêtes auraient du bouger lorqu'on défile verticalement.
Quelqu'un a une idée pour reproduire ce genre de comportement?
Il y a un truc qui m'échappe avec NSTableView: la vue quand est inclue dans une NSScrollView dans IB, alors que dans les faits la scrollview semble subordonnée à la tableview, dans la mesure où les entêtes des colonnes ne bougent pas quand on bouge les scrollers, alors que si la table aurait été "bêtement" subordonnée à la scrollview, les entêtes auraient du bouger lorqu'on défile verticalement.
Quelqu'un a une idée pour reproduire ce genre de comportement?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est la NSClipView qui contient la vue (dans ton cas la NSTableView) qui doit être défilée en fonction de la position des ascenseurs.
Schématiquement, ça done ça :
[Fichier joint supprimé par l'administrateur]
C'est pour ça que tu m'avais conseillé de ne pas me contenter d'un [tableView setNeedsDisplay:YES] mais plutot d'utiliser [[[tableview superview] superview] setNeedsDisplay:YES] pour forcer la scrollView entière à se redessiner y compris les headers de mes colonnes.
Par exemple une vue latérale d'entêtes et, à côté, une vue de lignes et colonnes scrolable pour reproduire une "tableView inversée" ? (entêtes latérales et scroll horizontal pour faire défiler dans les colonnes les éléments d'un NSArray)
Ce serait dur à faire ? ???
Faudrait repartir de zéro ou serait-il possible de sousClasser tableView ?
Ton exemple résume ce que je dois faire, si je l'ai bien compris: la première colonne doit toujours être visible (donc sensible au scroller vertical mais pas au scroller horizontal).
Dans Keynote (pour la table qui sert à l'entrée des donnes des graphiques), ils sont sous classé la scrollview, donc je suis parti dans cette direction aussi.
Par ailleurs, j'ai jetté un oeil sous IB (en basculant l'affichage en mode liste) et je suis surpris, après ce que nous a expliqué Bru, de voir qu' IB ne nous révèle, comme contenu de la ScrollView, que la tableView contenant ses tableColonnes ?
Pas de trace, dans la hierarchie, de NSCornerView, NSHeaderView ni de NSClipView ???
En fait, j'ai un peu simplifié les headersViews. Comme elles doivent défiler dans le sens horizontal, elles sont elles aussi incluses dans une NSClipView (qui ne peut que défiler horizontalement).
Pour IB, je ne sais pas trop comment il interprète les choses. Pour la cornerView, elle est accessible en reliant la tableView à une NSView déposée dans les instances de mainMenu.nib, puis en connectant au pseudo outlet "cornerView"
.
Merci Bru,
J'avais complètement zappé l'existence des NSClipView.
Il s'agirait donc, pour les header, d'être inclus dans une NSClipView qui ignore les appels de scroll vertical mais réponds à ceux du scroll horizontal ?
J'en était resté à Power plant où, si mes souvenirs sont bons, n'importe quelle vue pouvait être amenée à répondre aux appel d'un scroll pourvu qu'elle soit une "sub-view" du srcoll et ait implémenté les méthodes appropriées. (il me semble qu'un multiple héritage était nécessaire ici ...)
Donc Renaud "n'a plus qu'à faire une NSClipView qui répond au scrol vertical pour ses "header latéraux" ?
N'empèche que comme toi je me demande quelle cuisine fait I.B. pour ne pas afficher l'existence des clipView ???
Sans doutes ne sont elles crées et instanciée que dans le run-time ?
ça aurait été cool qu'elles figurent sous I.B. et permettent de choisir si les header sont latéraux et sensibles aux scroll vertical etc.. ce qui permettrait des tableView inversées qui manquent terriblement à cocoa.
Heureusement qu'il y'a Renaud qui s'y colle pour combler ce manque flagrant
Ceci dit Renaud, vérifie que XCode 2 ne corrige pas ce manque dans quelques mois avec l'arrivée de Tiger avant de te retrouver avec aussi peu de cheuveux que l'avatard de Tiff
Ce que tu veux faire Renaud sera difficile...
La seule solution la plus facile à mon avis est de créer une NSClipView "collée" (donc incluse la NSWindow/NSView qui contient ta tableView) à la scrollView, et qui reçoit les notifications de modification NSViewBoundsDidChangeNotification de la NSTableView afin de maintenir la synchronisation du déplacement vertical de la liste.
La solution complexe (mais peut être plus propre) est de sous-clasisser NSTableView.
.
Quand à sous classer NSTableView, j'y ai pensé, mais je me dis que ça n'a pas été fait chez Apple (pour Keynote), c'est qu'il est plus simple de refaire from scratch. OK, il y a des imbéciles partout (en particulier chez Apple pour l'optimisation des iApps), mais bon... :P
J'ai réussi à créer cette fameuse entête de ligne pour une NSTableView (comme dans Excel)...
Voici comment j'ai procédé :
1. dans IB, j'ai mis une custom view à gauche de ma tableView. Dans les infos, j'ai mis "custom class" à NSClipView. Je l'ai enfin reliée à un outlet qui va bien.
2. Dans le awakeFromNib de mon contrôleur, j'ai crée une NSCell prototype (pour contenir le texte de l'entête de chaque ligne).
3. Ensuite, j'ai créé une NSMatrix de largeur identique à celle de ma custom clip view, et de hauteur identique à celle de la tableView. Le nombre de cellulle est 1 en horizontal, et pour le vertical, c'est le nombre retourné par la méthode numberOfRowsInTableView: de ma tableView. J'ai mis le cellSize de la matrix à celle en hauteur d'une ligne de la tableView, et en largeur à celle de la custom clip view. Enfin le intercellSpacing est directement mis de la tableView vers la custom clip view.
3. Après, grâce à la notification NSViewBoundsDidChangeNotification de la NSClipView qui englobe la tableView, je synchronise le déplacement vertical de ma custom clip view avec celui des lignes de la tableView.
Voilà , y'a finalement pas trop de code, et ça marche impec.
.
En tous cas bravo.
sinon, on peut voir ta merveille ?
Il faut que je nettoie un peu le code, sinon je vous poste ça ce soir.
.
Bon j'al choisi l'optique de refaire un vue à part entière, parce que 1. il y avait plusieurs choses dont j'avais besoin non repris dans NSTableView, et je préfère dans ce cas parfois partir de 0 que me battre avec un truc que je ne maà®trise pas 2. ça m'amuse.
Bon alors les particularités principales de cette table sont 1. les vues d'en-tête de colonne sont elles mêmes des tables, et donc bénéficient des possibilités de celles-ci en temps normal, le datasource de ces tables est géré par la table principale mais si on veut vraiment personnaliser c'est possible 2. on peut fusionner des cellules, 3. on peut choisir le sens de remplissage (vertical ou horizontal).
Je dois encore ajouter le drag&drop, le copier coller, et des options pour mieux personnaliser ça.
Alors quelques screenshots:
[Fichier joint supprimé par l'administrateur]
Je retourne à mes études...
Sinon, ca a l'air d'être super. Bravo :adios!:
Bien entendu, comme c'est marqué plus haut le code est mis dans un framework, qui sera rendu public sous la licence LGPL (donc le code source sera dispo, et utilisable dans des softs payants pour peu qu'on en mentionne l'origine). Laissez moi juste finir mes examens que je paufine ça à mon aise
Par contre ClicCool pour les bindings ça risque de ne pas être évident: chaque cellule est identifiée par deux numéros, et non la colonne et le numéro de ligne, dans je vois mal comment inégrer ça dans un KVM, à moins que tu n'ais une bonne idée.
Merci
Quand on sait que tes exams ont commencé Lundi !!!
Les cellules sont numérotées de 1 (ou 0) à n ? sans trou ?
Genre pour colonnes :
1 2 3 4
5 6 7 8
et pour 2 colonnes :
1 2
3 4
5 6
7 8
Pour un table orientée verticalement
[tt]
(0,0) (1,0) (2,0)
(0,1) (1,1) (2,1)
(0,2) (1,2) (2,2)
[/tt]
Le piège aussi est qu'on peut demander à avoir un nombre indéterminé de cellules (toujours moyen d'aller plus bas, la taille de la table n'étant pas déterminée par le datasource), donc le datasource est susceptible de recevoir un message demandant d'éditer la cellulle (6,7) alors que la table est vide.
Et si à ça on rajoute la fusion des cellules. Je pense pas qu'il faille penser à ça dans les bindings. ça se fait en fait avec une méthode de délégué qui renvoie un NSRect. L'origine du Rect étant la position de la cellule placée en argument dans la zone fusionnée, et la taille étant la zone fusionnée.
Est-ce que les bindings permettront aussi de modifier le type de cellule utilisée en fonction du contenu?
ça dépend du temps de refroidissement du fut du canon ;D
Est-ce que les cellules de ton tableau existent réellent ?
ou celà fonctionne-t-il un peu comme dans les tableView avec une cellule d'édition unique pour chaque colonne ?
De quelle façon est déterminé la nature des donnée ? Est -elle explicite, dans une propriété (ou pseudo-propriété) du data source ?
Ou est-ce ta table qui teste les objets renvoyés ?
etc ...
P.S. faudraot qu'in en doscute p-e ?