object_method(thePatcher, gensym("wclose")) makes Max unhappy
Consider the following code snippet, where 'me' is a pointer to an arbitrary object
Object* thePatcher = NULL;
object_obex_lookup(me, gensym("#P"), &thePatcher);
// ASSERT (thePatcher != NULL)
object_method(jpatcher_get_toppatcher(thePatcher), gensym("wclose"));This works in that the object closes its top-level patcher (and the rest of the patch it's involved with). But it generates, as a rule, two "freeobject: <>: bad object" messages in the Max window.
Is there a better way for an object to cleanly close its Patcher? The [thispatcher] object pulls the trick off, but how?
Searching the archives, I see Tim suggested the technique once (but I think without testing). I originally tried the somewhat more brutal
object_free(jpatcher_get_toppatcher(thePatcher));but that also leads to the same bad object messages in the Max window.
I have reasons why I want to encapsulate this inside my object (rather than have the object send a wclose message for processing by thispatcher).
I could have sworn this was working without error messages last week. Then I ported to Windows and the error messages appeared. So I went back to Mac OS to check and, lo, there were error messages in the Max window.
For the record: occurs on both Mac OS and Windows, Max 5.1.7 (also occurred on a 5.0.x version on Windows before I updated to make sure it wasn't a version issue). Building on Mac with XCode 3.2.1; Windows with Visual Studio 2010.
For what it's worth: Overdrive was off on both machines. The machine I did this on before is 1000km away so I can't easily check the Overdrive setting. But I just switched Overdrive on here (Mac) and--hey, presto!--no error messages. Ditto on Windows. Looks like an Overdrive issue.
OK, so, why should the setting of Overdrive influence whether there are error messages when closing the TLP and, more importantly, how do I avoid the freeobject errors?
I suppose I could add code to (1) check current state of overdrive, (2) turn it on, (3) kill patcher window, and (4) restore previous Overdrive state. Surely there is an easier way?
Hmmm, Overdrive isn't the issue for you. I have one more idea about where my problem is coming from, but I'd rather take that off-list.
Would anyone from Cycling '74 be interested in taking a look at the code in question?