Here are some hints:
1) If the "thing" that caused the error isn't a gobj (i.e., if it's not a
comment, object, iemgui, etc.), then Pd probably doesn't know how to select it.
For example:
[namecanvas c]
[abc(
|
[s c]
Or:
[abc(
|
[s pd]
2) There are two error interfaces in Pd that I know of: pd_error and error.
pd_error stores a pointer to the last "thing" that caused an error. I guess an
external writer could technically store a pointer to anything there, but when
you try to find the last error it assumes it was a gobj.
Then there's plain old "error", which prints out the word "error:" to the Pd
window followed by whatever the error is. This is how the "argument number out
of range" error works. There's no reference to the thing that caused the
error, so you cannot search for it using "Find last error".
Unfortunately it looks like "pd_error" can't be used because the error is
caught in the midst of Pd parsing the message (in binbuf_eval of m_binbuf.c).
At that point it doesn't look like it keeps track of the object which sent the
message. Perhaps it could highlight the next object which would have received
the message, I'm not sure.
-Jonathan
On Thursday, January 23, 2014 9:23 AM, "[email protected]" <[email protected]> wrote:
thanks everyone for answering,
and for explaining my persistent blind spot.
i stumbled over it, because of a patch which gave continuously an
error message
"no method for 'abc'".
but 'finding last error'
always said 'sorry...'.
my question: is there any useful (hidden) info in this message/fact,
that Pd sees the error but can't tell where it happened?
rolf
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
