pdelges

as nobody replied to my old post about this topic (

https://cycling74.com/forums/jit-cellblock-coll-and-empty-cells-problems),

 let's try again but this time with Max5.1.4 under X.6.4

The following patch explains the procedure... Can somebody confirm this bug?

as nobody replied to my old post about this topic (https://cycling74.com/forums/jit-cellblock-coll-and-empty-cells-problems), let's try again but this time with Max5.1.4 under X.6.4

The following patch explains the procedure... Can somebody confirm this bug?


bug-coll-jit-cellblock

yes I can reproduce
mac os 10.4.11
max 5.1.4


First of all, I'm sorry for the delay in responding. I've been focused on other things, and have not been keeping up with the forum as much as I'd like.

The two issues that you are showing in this example patch are part of a fundamental problem with a jit.cellblock that is tied to a coll: the difficulty in maintaining structural integrity of a coll when the user interface isn't an exact match.

So, for example, in the first instance (typing 666 into cell 0/3), you are adding content to the colls row content. This changes the cellblock's understanding of the "structure" of the coll, and it reacts by removing the row (similar to the "remove" message to a coll) then adds it again, which places it at the end.

Secondly, the reason that the 666 moves into the second position is that cellblock (correctly) identified there to be an empty cell - but there is no such thing as an empty value in a coll. So cellblock gets rid of the empty cell and provides coll with a row that it can deal with.

The connection between jit.cellblock and coll is imperfect - especially when using inline edit mode. If you need to have a more robust data storage/management solution, you either need to use something other than jit.cellblock, or something other than coll.

To address the first problem, you could use the message (sort -1 1 ) to the coll after step 2.

To address the second problem you could fill empty spaces with a placeholder, (like •, option-8 on the mac), so your coll looks like this:

boring and inelegant, but possibly a workaround

To address the first problem, you could use the message (sort -1 1 ) to the coll after step 2.
To address the second problem you could fill empty spaces with a placeholder, (like •, option-8 on the mac), so your coll looks like this:

1, 1 • 666;
2, 2 3 4;
3, 3 4 5;
This could be automated somehow...
boring and inelegant, but possibly a workaround

Darwin, thanks for your honesty. As you proposed, I stopped using jit.cellblock with coll the very same day I discovered this bug (or let's call it 

 does work for the example I gave, but is not a viable abstract workaround. And the • idea (I used a more discrete char when I tried - btw, on my kb • is option-. :-) is, as you said, boring and inelegant.

Darwin, thanks for your honesty. As you proposed, I stopped using jit.cellblock with coll the very same day I discovered this bug (or let's call it imperfection).

@Terry:  sort does work for the example I gave, but is not a viable abstract workaround. And the • idea (I used a more discrete char when I tried - btw, on my kb • is  option-.  :-) is, as you said, boring and inelegant.

[bug?] coll & jit.cellblock