Christof Ressi wrote:
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
that can take a long time, even for vanilla objects ;-)
and there are so many 3rd party objects out there that would all need to be modified and re-released in order to fit these quite specific needs.
if it's not too big a project (IOhannes must decide), i think that such an object (like [canvaserror]) would do no harm to "everyday users" and would at least be very handy for those who have a need for it.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
since it would be part of IEMGUTS (which i think is where it belongs to), people usually know what they let themselves in for and would design their patches accordingly. for example, there's no real need for more than one [soundfiler] or [text define] objects in a canvas...
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
If the user queries the errno immediately after the method call, Pd's determinism guarantees that the error really belongs to that method call. We would have to reserve a special value (e.g. "0") to mean "no error".
sounds nice, too. but it wouldn't verbosely specify the type of error, like the console output, would it ?
just my 2c
best
oliver