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, "rolfm@dds.nl" <rolfm@dds.nl> 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






_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list