|Assignee:||Théo de la Hogue||% Done:|
|Target version:||MVC for 0.6|
I found something strange with the /address parameter, in the inspector of jcom.ui. If there is no address, the size will be wrong for a bpatcher with this jcom.ui inside.
And each time you open the [jcom.ui-inside]patcher, the address parameter is deleted. So if you want to save again your patcher hou have to manually re-type an address.
As always, an example is the best to understand.
#1 : Open jmod.mouse.maxhelp
#2 : Open mouse.view.maxpat
#3 : Save mouse.view.maxpat
The bpatcher in jmod.mouse.maxhelp has a wrong size.
May I create an issue in the redmine?
#2 Updated by Théo de la Hogue about 8 years ago
Actually this bug has no matter with the address attribute...
Try a simple patch with only a jcom.ui and instanciate it into another patch :
if the jcom.ui have a presentation width different from 150 pixel the jcom.ui is never resized to 150x35
else, if the jcom.ui have a presentation rect like 150x70 or 150x105, : the bug appears...
I look into the code and I noticed the method oksize() (which constrain the jcom.ui into rack size)
is called so many times during the creation (exactly at line 181 : jbox_new(&x->box, flags, argc, argv); ).
After this line the jcom.ui have mysteriously a rack-size of 150x35 in the case I mentionned before.
I put a post into oksize() method, and It seems this method is called everytime (resizing or not the jcom.ui) !!!
If I don't register the oksize() method in order to avoid the rack-constaint, all the mecanism works (I mean the bpatcher is well resized, ect...)
So, @Tim I guess I need to get you involved in this bug because it's really strange (I'm trying to make our code responsible but is there a way that is a Max trouble ?)