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