hi,
an attached crash-table.pd' is the
check-array.pd' from my previous
post, but modified to encapsulate array in a table. It crashes Pd
after a message (any message really) is sent to a renamed array
through a table object.
A check for null return from pd_findbyclass() in table_anything() in g_canvas.c would help...
Krashtof
#N canvas 207 232 521 362 12; #X msg 85 138 bang; #X obj 34 234 tabwrite~ mew; #X obj 287 234 table mew; #X msg 34 28 bang ; pd dsp 1 ; kitty rename grrr...; #X obj 287 181 r kitty; #X msg 289 28 ; kitty squeal; #X connect 0 0 1 0; #X connect 3 0 1 0; #X connect 4 0 2 0;
Yep, this (and previous crashes on renaming objects) ought to get fixed. I'm leaning toward simply preventing users from renaming things from messages. Perhaps the solution is to somehow detect whether a message is coming from the GUI or from the patch, and to disallow certain messages to come from the patch.
Self-deleting canvases are a more serious problem... I don't see any good way to allow users to have patches delete other patches, but to prevent a patch from deleting itself...
cheers Miller
On Thu, Dec 27, 2001 at 02:36:01PM +0100, Krzysztof Czaja wrote:
hi,
an attached
crash-table.pd' is the
check-array.pd' from my previous post, but modified to encapsulate array in a table. It crashes Pd after a message (any message really) is sent to a renamed array through a table object.A check for null return from pd_findbyclass() in table_anything() in g_canvas.c would help...
Krashtof #N canvas 207 232 521 362 12; #X msg 85 138 bang; #X obj 34 234 tabwrite~ mew; #X obj 287 234 table mew; #X msg 34 28 bang ; pd dsp 1 ; kitty rename grrr...; #X obj 287 181 r kitty; #X msg 289 28 ; kitty squeal; #X connect 0 0 1 0; #X connect 3 0 1 0; #X connect 4 0 2 0;