Adam Murray

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.

        post("path: " + getParentPatcher().getPath());

    private MaxQelem initializer = new MaxQelem(new Executable() {

            post("inside qelem, path: " + getParentPatcher().getPath());

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

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 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();
	}

getparentpatcher-getpath-does-not-always-work-in-the-constructor

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 

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

> I noticed some inconsistent behavior with getParentPatcher().getPath 

> 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 

>         post("path: " + getParentPatcher().getPath());

>     private MaxQelem initializer = new MaxQelem(new Executable() {

>         public void execute() {

>             post("inside qelem, path: " + getParentPatcher().getPath());

>     protected void notifyDeleted() {

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

>
> 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


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.

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.


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.

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.


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