pertes de connexion sur copy paste

groumpfgroumpf 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 !

Réponses

  • ClicCoolClicCool Membre
    00:48 modifié #2
    Salut groumpf :)

    Il semble que ce soit un manque dans I.B. :(  >:(
  • groumpfgroumpf Membre
    00:48 modifié #3
    c'est bizarre car dans la doc en ligne on a l'impression qu'ils ont une solution.

    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...
  • mpergandmpergand Membre
    00:48 modifié #4
    Je crois comprendre ton courroux groumpf, car en jetant un ½il sur le nib matrix1000, j'ai constaté que tu définissais un outlet et une action pour chacun des paramètres !! Au pif y en a pas loin de 200 !!  'tain pas la joie ! Pour le DX c'est du même ordre et je me voyais absolument pas procéder de cette façon, vraiment trop gonflant ! On doit pouvoir faire autrement:

    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:
    <br />/*       voice parameters<br />  <br />          VoiceParam[][0]         type de param<br />             VoiceParam[][1]         val mini<br />          VoiceParam[][2]         val max<br />           VoiceParam[][3] sysEx1<br />            VoiceParam[][4] sysEx2<br />    */<br /><br />  static final short[][] VoiceParam=              <br />                  {<br />                         {ParamType_Num,0,31,0x12,0},    // Attack Rate op1<br />                                {ParamType_Num,0,31,0x12,1},    // Decay 1 Rate<br />                           {ParamType_Num,0,31,0x12,2},    // Decay 2 Rate<br />                           {ParamType_Note,0,1,0x12,8},            // Break point<br />                            {ParamType_FrqCoarse,0,63,0x12,11},// frq coarse<br />                          {ParamType_SNum,0,6,0x12,12}, // detune<br />                           {ParamType_Alg,0,7,0x12,52},            // Alg  <br /><br />    .......<br /><br />   
    



    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.
  • ClicCoolClicCool Membre
    00:48 modifié #5
    D'accord avec toi mpergand :)

    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 :( :o
  • groumpfgroumpf Membre
    00:48 modifié #6
    c'est très interessant ce que tu dis mpergand,
    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
  • ClicCoolClicCool Membre
    00:48 modifié #7
    Et tu peux pas créer ces objets d'interface "on the fly" ? avec un algorythme de placement décalé ?
    Voire utiliser une (des) matrices ?
  • groumpfgroumpf Membre
    00:48 modifié #8
    dans 1096306629:

    Et tu peux pas créer ces objets d'interface "on the fly" ? avec un algorythme de placement décalé ?
    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 !
  • mpergandmpergand Membre
    00:48 modifié #9
    dans 1096310227:

    dans 1096306629:

    Et tu peux pas créer ces objets d'interface "on the fly" ? avec un algorythme de placement décalé ?
    Voire utiliser une (des) matrices ?


    heu, surement !



    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.
  • ClicCoolClicCool Membre
    00:48 modifié #10
    dans 1096310849:

    dans 1096310227:

    dans 1096306629:

    Et tu peux pas créer ces objets d'interface "on the fly" ? avec un algorythme de placement décalé ?
    Voire utiliser une (des) matrices ?


    heu, surement !



    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...
    <br />[arrayDeMesChamps objectAtIndex: leTag] = [[NSTextField alloc] initWithFrame: maFramePourLeTag];
    

    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 ... :D
  • TiffTiff Membre
    00:48 modifié #11
    D'accord pour définir le frame par le code, mais qu'en est-il si l'utilisateur agrandit la fenêtre ? On peut choisir l'origine du repère autrement que en bas à  gauche (ou en haut, tiens, j'sais plus) ? Bref, les histoires de ressorts, bien pratiques sous I.B.
  • mpergandmpergand Membre
    septembre 2004 modifié #12
    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 !.


    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.
  • ClicCoolClicCool Membre
    00:48 modifié #13
    dans 1096316277:

    D'accord pour définir le frame par le code, mais qu'en est-il si l'utilisateur agrandit la fenêtre ? On peut choisir l'origine du repère autrement que en bas à  gauche (ou en haut, tiens, j'sais plus) ? Bref, les histoires de ressorts, bien pratiques sous I.B.


    Tu peux sans problème gérer les ressorts à  la volée si tu veux ;D

    num {
      NSViewNotSizable = 0,
      NSViewMinXMargin = 1,
      NSViewWidthSizable = 2,
      NSViewMaxXMargin = 4,
      NSViewMinYMargin = 8,
      NSViewHeightSizable = 16,
      NSViewMaxYMargin = 32
    };
    Discussion

    These constants are described in NSView?s setAutoresizingMask:.
  • ClicCoolClicCool Membre
    00:48 modifié #14
    dans 1096316511:

    Je crois que tu m'as mal compris, effectivement pas question de se taper 200 outlets/actions.


    Oui mpergand, à  la relecture de ton post je pense que j'avais en effet mal interprété tes pensées  :-\
  • TiffTiff Membre
    00:48 modifié #15
    Un peu plus de 10 minutes pour répondre ? tu exagères, là  !

    Non, non, pitié !  o:)
  • ClicCoolClicCool Membre
    00:48 modifié #16
    Je regarde  >:D "les Diaboliques" >:D , j'peux pas être au four et au moulin  ;D ;D  :P
  • groumpfgroumpf Membre
    00:48 modifié #17
    dans 1096313856:

    Quand t'as 200 champs avec leurs outlets et actions, pas question des les définir tous sous I.B. !


    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.

  • ClicCoolClicCool Membre
    00:48 modifié #18
    en effet, il est plus facile de retoucher sous IB que dans le code (quoique en utilisant des view conteneur dans lesquelles tu installes tes objets, il suffit de déplacer le conteneur pour les objets soient créés au nouvel emplacement sans modifier le code ...)

    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. ;)
Connectez-vous ou Inscrivez-vous pour répondre.