Bug: Opening Max4 patcher with Max5 moves UI objects to top left corner
This only happens with one patcher, but opening the Max4 patcher with Max5 moves all the UI objects to the top left corner, piling multiple objects on top of each other. PNGs attached of the patcher window as it appears in Max 4 and the same patcher file after opening on Max5.
Before you blame the custom UI object, every other patcher using that object converts nicely when opening in Max5.
If somebody would like to look at the patcher files, please let me know.
Max 5.1.7 on Mac OS 10.6.6. Patcher files created with Max 4.6.3.
I would definitely blame the 3d party object ;-) It really depends how you handle the stdargs method. Feel free to post an example or send it privately.
Well, the other iCE objects are positioned correctly, and all the iCE objects use pretty much the same code.
But ice.lattice is a UI object. Since there wasn't anything in the documentation about stdargs, nor in the recommended sample project, uitextfield, I think you can cut me some slack for not having implemented a stdargs method yet.
As for pointing fingers… I wonder if the problem is that Max5 is making assumptions about how the box coordinates are saved by a UI object in a Max4 patcher. Lattice, in an effort to keep file size small, did the following inside its Max4 psave method:
if (me->coreObject.b_hidden) {
binbuf_vinsert( ioBBuf, "ssssllls", gensym("#P"), gensym("hidden"), gensym("user"), gensym((char*) kClassName), Point2Long(tl), Point2Long(br), maxFont, me->name);
}
else {
binbuf_vinsert( ioBBuf, "sssllls", gensym("#P"), gensym("user"), gensym((char*) kClassName), Point2Long(tl), Point2Long(br), maxFont, me->name);
}(note how top&left coordinates are, following classic Mac OS conventions, packed into a single long integer; ditto bottom&right). Although if this is the issue, then I wonder why I've not had the positioning problem with a dozen other Max4 patches I've converted.
In any case, if I can figure out how the stdargs thing works, then I can probably get this sorted out.
stdargs gets the value stored as an array of t_atom, so you might be able to do something like this:
t_max_err yourobject_stdargs(t_dictionary *d, t_symbol *s, long argc, t_atom *argv)
{
long left, top, width, height, right, bottom;
t_atom at[4];
if (d && argc > 1) {
left = /* some method to extract from atom_getlong(argv) the left coordinate */;
top = /* some method to extract from atom_getlong(argv) to top coordinate */;
right = /* some method to extract from atom_getlong(argv+1) to right coordinate */;
bottom = /* some method to extract from atom_getlong(argv+1) the bottom coordinate */;
width = right-left;
height = bottom-top;
atom_setlong(at+0, left);
atom_setlong(at+1, top);
atom_setlong(at+2, width);
atom_setlong(at+3, height);
dictionary_appendatoms(d, gensym("patching_rect"), 4, at);// rect is x y width, height, like t_rect, but with long args
}
return MAX_ERR_NONE;
}
Thanks, that's very clear.
I think what was irritating me in the jslider example were the lines
horiz = (s == ps_hslider) ? 1 : 0;
type = (s == ps_slider) ? 0 : 1; // Miller's original slider (relative mousing by default)First, I'm not clear how the stdargs message would be sent, in this example, with different t_symbol* parameters. Second, I'm not sure with the type variable whether canonical TRUE indicates that the data came from the original Miller slider, or if FALSE indicates the original. I think it's the latter. If I were more sure, then I think I would better understand what's going on later in the code.
I'm sort of going into hiding in an undisclosed location for a week starting tomorrow, but I will try to see if I can get take a wee peek at any messages on the forum.
yeah that's confusing, since there were 3 different sliders (slider, uslider, hslider), the only horizontal one is hslider, and only slider had the relative mousing feature.
Thankfully this is just one object now, and the behavior stays the same when you open a Max 4 patcher because of the magic stdargs ;-)