Forums > Java

getParentPatcher().getPath() does not always work in the constructor

March 4, 2008 | 7:45 am

I noticed some inconsistent behavior with getParentPatcher().getPath() when used inside a constructor.

When I open the patch for the first time, it will return null. If I delete the mxj object and undo, then it will return the correct path. It’s like the parent patcher doesn’t initialize until after the mxj object, which seems backwards to me. Is it a bug?

I can work around this problem by using a MaxQelem, which so far seems to work flawlessly.

import com.cycling74.max.Executable;
import com.cycling74.max.MaxObject;
import com.cycling74.max.MaxQelem;

public class test extends MaxObject {

public test() {
post("path: " + getParentPatcher().getPath());
initializer.set();
}

private MaxQelem initializer = new MaxQelem(new Executable() {
public void execute() {
post("inside qelem, path: " + getParentPatcher().getPath());
}
});

protected void notifyDeleted() {
initializer.release();
}

}


March 4, 2008 | 4:23 pm

seems like a good workaround. i don’t know exactly why this happens
but i remember similar behavior when i was working on that stuff. its
like the pointer to the parent patcher isn’t initialized until the
entire patcher loads. you could also see if it is valid in the
loadbang() method.
t

On Mar 3, 2008, at 23:45 PM, Adam Murray wrote:

>
> I noticed some inconsistent behavior with getParentPatcher().getPath
> () when used inside a constructor.
>
> When I open the patch for the first time, it will return null. If I
> delete the mxj object and undo, then it will return the correct
> path. It’s like the parent patcher doesn’t initialize until after
> the mxj object, which seems backwards to me. Is it a bug?
>
> I can work around this problem by using a MaxQelem, which so far
> seems to work flawlessly.
>
>
> import com.cycling74.max.Executable;
> import com.cycling74.max.MaxObject;
> import com.cycling74.max.MaxQelem;
>
> public class test extends MaxObject {
>
> public test() {
> post("path: " + getParentPatcher().getPath());
> initializer.set();
> }
>
> private MaxQelem initializer = new MaxQelem(new Executable() {
> public void execute() {
> post("inside qelem, path: " + getParentPatcher().getPath());
> }
> });
>
> protected void notifyDeleted() {
> initializer.release();
> }
>
> }
>
>
> –
> Adam Murray
> compusition.com


March 4, 2008 | 10:41 pm

It’s the same in JavaScript, where you can’t get this.patcher’s parent patcher immediately, it needs to be done from the js loadbang().

And there are similar issues in native C, we can’t even rely on loadbang(), we need to defer_low() if we want to know anything about the patcher structure. Seems the parent heirarchy isn’t fully discoverable until some time after the patcher loadbangs its contained objects. There was some discussion of this on the dev-list recently.


March 4, 2008 | 11:20 pm

Quote: johnpitcairn wrote on Tue, 04 March 2008 14:41
—————————————————-
> It’s the same in JavaScript, where you can’t get this.patcher’s parent patcher immediately, it needs to be done from the js loadbang().
>
> And there are similar issues in native C, we can’t even rely on loadbang(), we need to defer_low() if we want to know anything about the patcher structure. Seems the parent heirarchy isn’t fully discoverable until some time after the patcher loadbangs its contained objects. There was some discussion of this on the dev-list recently.
—————————————————-

Too bad the Max APIs don’t provide an onPatchInit() callback.


Viewing 4 posts - 1 through 4 (of 4 total)