another possible way would be to talk to a regular max [receive]
object from within mxj, because of it’s global scope, but something
in the back of my head tells me, that this is not possible. wrong?
(would be nice…)
thanks.
volker.

public class namedObj extends MaxObject
{

private MaxPatcher _p = null;

namedObj (Atom[] a) {
_p = this.getParentPatcher(); // how can i change this to
reference another patcher?
}

public void ss( int i ) {
MaxBox b = _p.getNamedBox(“myNum”);
b.send(i);
}
}

I am sure there is more than one way to do what you want but this is
what came
to mind for me.

Topher

I have a hack that works, but it involves people putting things in
the c74/java/lib folder, which I presume you would rather I didn’t
do. will this be forthcoming in a future version of the mxj sdk, or
am I approaching this from the wrong angle completely?

best regards,
r.

> hi topher, could you be a little more explicit in how you would
> actually execute this plan (i.e. the global static table part)?

well all the mxj instances are running in the same JVM so if a
variable is declared static, a hashtable for instance, all instances will have the same reference.

> I have a hack that works, but it involves people putting things in
> the c74/java/lib folder, which I presume you would rather I didn’t
> do. will this be forthcoming in a future version of the mxj sdk, or
> am I approaching this from the wrong angle completely?

why not?it is fine to put things in that folder. it is automatically
searched upon JVM startup for any jars so it makes the most sense
to put jarred code there.

topher

> why not?it is fine to put things in that folder. it is
> automatically searched upon JVM startup for any jars so it makes
> the most sense
> to put jarred code there.
>
the only reason I put stuff there is to access package-private
methods/data in com.cycling74.max.*. presumably the access levels are
set for a reason, no? if not, could you make mxjObjectWasDeleted()
package-private instead of object-private as well? it would make my
hack a little cleaner. thanks.

r.

couldn’t you just add another method to your object.
registerNotifyDeleted(Object o) or something like that.
Than you could notify everyone that registed with that instance in
your overridden mxjObjectWasDeleted.
Just an idea. There is always more than one way to skin a cat.
Topher

package com.cycling74.max;

/**
* boxless max object wrapper hack by r.
*
* for this to work it must live in c74/java/lib
*/
public abstract class MaxBoxlessObject extends MaxObject {
/**
* expose public version of mxjObjectWasDeleted()
* can’t get at any private stuff in MaxObject, so
* this is the best we can do. presumably all the
* instance variables listed will let go when this
* object is garbage collected anyway, no?
*/
public void delete() {
MaxContext.unregister(this);
notifyDeleted();

// mName = null;
setName(null); // public equivalent

// mInlets = null;
declareInlets(NO_INLETS); // next best thing

// mOutlets = null;
declareOutlets(NO_OUTLETS); // next best thing. what about info
outlet? seems like
// we can’t mess with it once it’s been created..

// mInletAssist = null;
setInletAssist(null); // public equivalent

// mOutletAssist = null;
setOutletAssist(null); // public equivalent

// _attributes = null;
// stumped

// _flash_watch = null;
// this should almost always be null it seems,
// unless delete() gets called in the middle of
// doing something else which seems impossible.

// WATCHME = null;
// stumped

// _source_editor = null;
// stumped
}
}

really it seems to me that the important things in here are
MaxContext.unregister(this) and notifyDeleted(), but (a) you go to
all the trouble to set everything else to null (or jad is telling
stories), and (b) perhaps in future versions there’ll be some more
critical stuff in there that I similarly can’t deal with. my solution
seems a little fragile from my point of view.

best regards,
r.