pertes de connexion sur copy paste
groumpf
Membre
je voudrais déplacer des objets dans IB en gardant les connexions, le pb c'est qu'avec copy&paste elles sont perdues, et y compris avec la méthode trouvée sur le site Apple qui est option-drag dans une autre fenetre et ensuite dans la fenetre cible...
J'ai Xcode 1.5 et IB 2.4.2
groumpf alors !
J'ai Xcode 1.5 et IB 2.4.2
groumpf alors !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Il semble que ce soit un manque dans I.B. >:(
Peut-etre que cette solution a fonctionné sur une certaine version et plus ensuite.
En tout cas heureusement que je programme pour m'amuser car sinon je piquerai une crise avec des bugs comme ça !
J'imagine la solution : bidouiller directement dans le NIB...
1) on peut utiliser les tags pour retrouver un objet avec la méthode viewWithTag de NSView, de plus ce tag pourra correspondre à un numéro de paramètre, généralement indiquant sa position dans un patch, pratique pour la lecture/ecriture des valeurs de ce paramètre.
2) pour les actions, c'est pas aussi simple, je pense que tu pourrais essayer de dériver chacun des types de contrôles que tu utilises ( NSSlider, NSPopUpButton, etc) et en intervenant sur les méthodes de NSResponder, le tag te permettant, ici aussi, de retrouver le paramètre concerné. C'est cette méthode que j'utilisais en C++ avec CW, le multi héritage était bien pratique dans ce cas, tout ces contrôles héritant aussi d'une classe OMidi, implémentant ce qui concernait le MIDI, comme l'envoi du msg sysex lors du changement de val.
En Java ou ObjC, je crois que c'est moins simple à faire.
Pour TX7 Editor, j'ai utilisé une technique différente, si tu regardes le fichier nib de l'editeur, tu verras que des objets de type ParamController recouvrent tous les objets correspondant à un paramètre. C'est donc cette classe ParamController, qui lors d'un clic, recherche le parametre se trouvant en dessous et l'identifie grace à la valeur du tag de cette objet. Cette méthode est très souple, elle permet de définir des groupes de paramètres en créant des types particuliers de ParamController (comme des OpParamController pour les paramètres de chaque opérateur du DX), de plus la classe de base paramController est indépendante du type de synthé et peut donc être réutilisés dans un autre editeur, sans aucune modification.
Comme tu le vois, tout est centré autour de cette valeur tag, j'ai d'autre part un tableau de valeurs me permettant, toujours à partir de ce tag, de retrouver diverses informations sur le paramètre correspondant:
Pour conclure, les outlets c'est bien, mais c'est pas adapté à toutes les situations... les tags aussi c'est bien pratique et je constate que l'on évoque rarement cette alternative.
les tags sont sous-utilisés et entre les outlets, actions et autres bindings, on a du mal à trouver leur juste place.
Ceci-dit d'après ce que tu as vu du projet de groumpf, je compati face à la tache fastidieuse qui l'attend
j'avais deja trouvé ca fastidieux de faire toutes les connexions (j'ai encore mal au poignet) pour le matrix, que j'imaginais pas faire la meme chose pour le FS1R !
On a l'impression que IB sert a faire des interfaces avec 3 objets...pas des éditeurs de synthé en tout cas
Je vais donc regarder cette histoire de tag (champ qui m'intriguait par ailleurs) parce que c'est vrai que mon code est assez délirant en nombre d'outlets et d'actions, et si je pouvais m'affranchir du placement ce serait cool.
merci bien
Voire utiliser une (des) matrices ?
heu, surement !
l'éditeur n'est que mon 2nd programme en Cocoa et franchement j'y comprend pas grand chose. D'habitude je fais du Java et ca me semble beaucoup + clair car tout est dans le code, il suffit de le lire. Mais en Cocoa il y a 10000 concepts à comprendre, sans parler d'Objective-C, de la gestion mémoire (beurk)...
Ce qui est bien en Java c'est qu'il suffit de couper&coller le code pour faire du refactoring, mais bon, faut le temps quoi !
Hum, tu procèdes à l'aveugle, c'est pas trop le pied. Pour une serie d'objet bien alignés peut-être ...
Non InterfaceBuilder c'est bien et puis les tags c'est ce que l'on utilise depuis toujours, les outlets c'est vraiment particuler à IB et à Cocoa.
Tu plaisante là n'est-ce pas ? ???
Quand t'as 200 champs avec leurs outlets et actions, pas question des les définir tous sous I.B. !
Comme dit groumpf IB est pas fait pour ça et toute modification y prend l'allure d'un cauchemard !.
Pour ce qui est des outlets t'as pas besoin d'en créer puisque tu crées les objets à la volée.
Tu peut même les regrouper dans un tableau où tu fais correspondre l'indice dans le tableau avec le Tag justement.
Avec un tableau de NSTextFied* par exemple tu fais une boucle avec...
Ensuite t'as plus qu'à attribuer ton tag, ton titre, la target et l'action ... bref tout ton bazard quoi.
(La plus parts des méthodes nécessaires ici sont dans NSControl)
Pour la frame, ce n'est qu'un NSRect dont tu calcules la position en fonction de l'indice.
Pour ce qui est d'inclure les champs ainsi crés dans une autre vue, tu as bien sur les méthodes de NSView gérant les subView et superView ....
Bien sur tu as aussi une option intermédiare consistant à ne créer dans IB qu'un seul objet de la série avec ses attributs et son outlet puis (grâce à son outlet) de le copier en appliquant à la copie un setFrame avec l'offset approprié à son indice.
Bref y'a rien de bien terrible là dedans et c'est terriblement propre et efficace dans des projets aux multiples objets ...
Je crois que tu m'as mal compris, effectivement pas question de se taper 200 outlets/actions.
Tu parles de créer des objets à la volée, je trouve pas ça terrible non plus, et puis pour moi qui aime bien fignoler les interfaces, c'est pas la bonne méthode.
Les constructeurs d'interface comme IB sont quand même bien pratique pour faire des interfaces complexes .
Non, la soluce est simple, il suffit qu'il définisse une valeur tag pour tous les objets de ces paramètres et voila. Pour les actions, on peut simplifier la chose en ne définissant qu'un target par groupe de paramètres (contenus dans un NSBox ?).
Tu pourrais avoir raison, s'il s'agit de faire une matrice de 20x10 textfield, par programmation c'est simple à faire, mais dans IB avec les NSMatrix c'est encore plus simple, je trouve.
Tu peux sans problème gérer les ressorts à la volée si tu veux ;D
Oui mpergand, à la relecture de ton post je pense que j'avais en effet mal interprété tes pensées :-\
Non, non, pitié !
en fait, c'est déjà fait ! (il marche mon soft, peut-etre mal codé mais il marche)
Je voulais juste changer l'emplacement de certains controles mais comme IB perd les connexions...
Sinon je préfère utiliser IB pour positionner les éléments, si c'est pour faire un truc moche c'est pas la peine...
Et puis c'est en utilisant le logiciel qu'on s'apercoit les défauts d'emplacement, donc il faut pouvoir retoucher facilement.
Une autre possibilité est justement peut être aussi de lister dans ton code les subviews une à une afin de les identifier et de les connecteur dans l'awakeFromNib.