Mattijs

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

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. 

from-jit-cellblock-to-waveform-focus-isnt-transferred

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.

(note, there are loadmess's in the patch)

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 

I can confirm that clicking in the waveform~ object does not release 

the focus. In the meantime, this workaround seems to solve the issue.

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

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.

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 

> I can confirm that clicking in the waveform~ object does not release 

> the focus. In the meantime, this workaround seems to solve the issue.

> #P newobj 411 425 60 196617 thispatcher;

> #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 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 message 274 274 93 196617 brgb 255 255 255;

> #P message 176 274 93 196617 brgb 100 100 255;

Thanks for confirming and thanks for the workaround. 

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


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 

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

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 

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?

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

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?

    outlet(0, this.patcher.wind.dirty);

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

function bang()
{
	outlet(0, this.patcher.wind.dirty);
}

Great, thanks. This will provide a fine workaround for the moment.

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?

>     outlet(0, this.patcher.wind.dirty);

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


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