from jit.cellblock to waveform~: focus isn't transferred


    Jun 06 2007 | 3:50 pm
    Hi cycling,
    The focus issues when using cellblock have been discussed before. The current approach is that to use keys outside cellblock the user has to click outside the cellblock.
    When I click outside cellblock but instead of clicking the background I click a waveform~, the focus is not transferred to the keys object, even though waveform~ doesn't need key input.
    Guess cellblock calls for a new feature in max: every interface object should know what to do with key focus when it is clicked..
    Best,
    Mattijs

    • Jun 18 2007 | 3:26 pm
      Hi, I'm sorry to raise this once more but it is a serious problem. Here is an example patch with steps to reproduce. Please have a look and tell me if this can be registered as a bug or a missing feature.
      Mattijs
      (note, there are loadmess's in the patch)
    • Jun 18 2007 | 4:33 pm
      On 18 juin 07, at 17:26, Mattijs Kneppers wrote:
      > Hi, I'm sorry to raise this once more but it is a serious problem.
      > Here is an example patch with steps to reproduce. Please have a
      > look and tell me if this can be registered as a bug or a missing
      > feature.
      I can confirm that clicking in the waveform~ object does not release
      the focus. In the meantime, this workaround seems to solve the issue.
      ej
    • Jun 18 2007 | 4:56 pm
      Hi EJ,
      Thanks for confirming and thanks for the workaround.
      The only problem I have with the workaround is that after these script commands the patcher is registered as dirty. I get a 'do you want to save' dialog when I close the patch even though I didn't change anything.
      Mattijs
      Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 18:33
      ----------------------------------------------------
      > On 18 juin 07, at 17:26, Mattijs Kneppers wrote:
      >
      > > Hi, I'm sorry to raise this once more but it is a serious problem.
      > > Here is an example patch with steps to reproduce. Please have a
      > > look and tell me if this can be registered as a bug or a missing
      > > feature.
      >
      > I can confirm that clicking in the waveform~ object does not release
      > the focus. In the meantime, this workaround seems to solve the issue.
      >
      > ej
      >
      > #P window setfont "Sans Serif" 9.;
      > #P window linecount 1;
      > #N thispatcher;
      > #Q end;
      > #P newobj 411 425 60 196617 thispatcher;
      > #P window linecount 2;
      > #P message 411 385 228 196617 script new tutu number -112 -153 35 9 0
      > 0 0 3 , script send tutu select , script delete tutu;
      > #P window linecount 1;
      > #P newex 176 375 89 196617 loadmess set loop;
      > #P newex 243 396 146 196617 loadmess replace drumloop.aif;
      > #P newex 176 396 65 196617 buffer~ loop;
      > #P newex 176 255 44 196617 del 100;
      > #P newex 176 235 30 196617 t b b;
      > #P newex 176 215 38 196617 sel 32;
      > #P newex 176 195 40 196617 key;
      > #P message 274 274 93 196617 brgb 255 255 255;
      > #P message 176 274 93 196617 brgb 100 100 255;
      > #P user waveform~ 176 296 200 74 3 9;
      > #W mode select;
      > #W mouseoutput continuous;
      > #W unit ms;
      > #W grid 1000.;
      > #W ticks 0;
      > #W labels 1;
      > #W vlabels 0;
      > #W vticks 1;
      > #W bpm 120. 4.;
      > #W frgb 33 0 0;
      > #W brgb 100 100 255;
      > #W rgb2 0 95 255;
      > #W rgb3 0 0 0;
      > #W rgb4 0 0 0;
      > #W rgb5 190 137 255;
      > #W rgb6 100 100 100;
      > #W rgb7 100 100 100;
      > #P user jit.cellblock 24 195 166 369 3 9 5 10 45 17 0 1 1 0 1 1 1 1 1
      > 0 0 0 255 255 255 0 0 0 0 0 0 191 191 191 0 0 0 215 215 240 1 1 1 0 4
      > 0 0 0;
      > #P connect 1 3 11 0;
      > #P connect 11 0 12 0;
      > #P connect 6 1 3 0;
      > #P connect 9 0 8 0;
      > #P connect 2 0 1 0;
      > #P connect 3 0 1 0;
      > #P connect 10 0 1 0;
      > #P connect 7 0 2 0;
      > #P connect 6 0 7 0;
      > #P connect 5 0 6 0;
      > #P connect 4 0 5 0;
      > #P window clipboard copycount 13;
      >
      >
      ----------------------------------------------------
    • Jun 18 2007 | 5:31 pm
      On 18 juin 07, at 18:56, Mattijs Kneppers wrote:
      > Thanks for confirming and thanks for the workaround.
      >
      > The only problem I have with the workaround is that after these
      > script commands the patcher is registered as dirty. I get a 'do you
      > want to save' dialog when I close the patch even though I didn't
      > change anything.
      Then send clean to thispatcher :)
      ej
    • Jun 18 2007 | 5:37 pm
      Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 19:31
      ----------------------------------------------------
      > On 18 juin 07, at 18:56, Mattijs Kneppers wrote:
      >
      > > Thanks for confirming and thanks for the workaround.
      > >
      > > The only problem I have with the workaround is that after these
      > > script commands the patcher is registered as dirty. I get a 'do you
      > > want to save' dialog when I close the patch even though I didn't
      > > change anything.
      >
      > Then send clean to thispatcher :)
      Ok, but what if I did change something? If I simply send clean to thispatcher I will lose my previous dirty state.
      Is there a way to query the current dirty state from thispatcher?
      Mattijs
    • Jun 18 2007 | 5:59 pm
      On 18 juin 07, at 19:37, Mattijs Kneppers wrote:
      > Ok, but what if I did change something? If I simply send clean to
      > thispatcher I will lose my previous dirty state.
      >
      > Is there a way to query the current dirty state from thispatcher?
      From js:
      function bang()
      {
      outlet(0, this.patcher.wind.dirty);
      }
      ej
    • Jun 18 2007 | 9:09 pm
    • Jun 19 2007 | 8:22 am
      Great, thanks. This will provide a fine workaround for the moment.
      Mattijs
      Quote: Emmanuel Jourdan wrote on Mon, 18 June 2007 19:59
      ----------------------------------------------------
      > On 18 juin 07, at 19:37, Mattijs Kneppers wrote:
      >
      > > Ok, but what if I did change something? If I simply send clean to
      > > thispatcher I will lose my previous dirty state.
      > >
      > > Is there a way to query the current dirty state from thispatcher?
      >
      > From js:
      >
      > function bang()
      > {
      > outlet(0, this.patcher.wind.dirty);
      > }
      >
      > ej
      >
      ----------------------------------------------------