Exit Only

I noticed that if I write [table @size 30 @range 50], table keeps its default values. Is it supposed to behave like this? If I modify the attributes via the inspector they do change.

I realize I could just use a size message, etc but I thought attributes were supposed to get around this.

I noticed that if I write [table @size 30 @range 50], table keeps its default values. Is it supposed to behave like this? If I modify the attributes via the inspector they do change. 

table-doesnt-respond-to

> I noticed that if I write [table @size 30 @range 50], table keeps its

> default values. Is it supposed to behave like this? If I modify the

> attributes via the inspector they do change.

Is there any reason why you would not want to set it in the inspector?

One observation: if I open the patch, it takes @size as name...

I agree, there is much confusion with the differentiation between 

arguments and attributes. The reference to table states no arguments 

which is wrong, and it states size and range as attributes which should 

I'd like to hear a comment form cycling on these confusions...

Btw. most objects which take arguments claim to have no arguments in the 

Though this is obviously not correct, it remains confusing...

Nick Inhofe schrieb:
> I noticed that if I write [table @size 30 @range 50], table keeps its
> default values. Is it supposed to behave like this? If I modify the
> attributes via the inspector they do change.

I agree, there is much confusion with the differentiation between 
arguments and attributes. The reference to table states no arguments 
which is wrong, and it states size and range as attributes which should 
make your patch work...

Btw. most objects which take arguments claim to have no arguments in the 
reference...
Though this is obviously not correct, it remains confusing...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


There are a few objects that incorrectly state they do not accept arguments in the documentation. We are in the process of correcting them. Not all objects with attributes set in the inspector can be set via the @ syntax as arguments. table is one of them. There is not necessarily a good reason, other than in some cases when @ handling was added toward the end of the development cycle, we ended up breaking the object so we decided we would defer this feature until a point where we had more time to do it properly.

ok! just wanted the official response. I ran into that naming problem too, I did fix it by writing

but obviously this didnt fix the attribute problem. This is no biggie though, and I can just go through the inspector and/or use size/range messages.

ok! just wanted the official response. I ran into that naming problem too, I did fix it by writing 

but obviously this didnt fix the attribute problem.  This is no biggie though, and I can just go through the inspector and/or use size/range messages.


> There is not necessarily a good reason, other than in some cases when

> @ handling was added toward the end of the development cycle, we

> ended up breaking the object so we decided we would defer this

> feature until a point where we had more time to do it properly.

Thanks, for the clarification. table can happily live without attribute 

David Zicarelli schrieb:
> There is not necessarily a good reason, other than in some cases when
> @ handling was added toward the end of the development cycle, we
> ended up breaking the object so we decided we would defer this
> feature until a point where we had more time to do it properly.

Thanks, for the clarification. table can happily live without attribute 
arguments...

table doesn't respond to