On 11 Feb 2008, at 14:59, felix wrote:
Cool, that fixed a few of the test cases.
I've committed one more bugfix to this.
it fixes the crazy situation where you create the composite view, it reports its absolute bounds as incorrect, and then after the window is finished .fronting it then tells you the correct bounds.
I'm putting all of these test cases into unit tests, so there should be no slippage.
there are still a few documented failures in there.
Thanks for doing that.
SCCompositeView.test
- this has one failure, and one example where only humans can tell that it failed.
SCScrollView.test
I think the issue with the scrollview failing here has to do with the reliance on mLayout for absolute bounds, which is used a bit differently in the scrollview.
I think I have a solution though.
1. add this to SCScrollTopView::getProperty
if (strcmp(name, "absoluteBounds")==0) {
if (!(isKindOfSlot(slot, s_rect->u.classobj))) {
return errWrongType;
}
SCRect bounds = NStoSCRect([mNSScrollView frame]);
PyrSlot *slots = slot->uo->slots;
SetFloat(slots+0, bounds.x);
SetFloat(slots+1, bounds.y);
SetFloat(slots+2, bounds.width);
SetFloat(slots+3, bounds.height);
return errNone;
}
2. remove bounds from the same
3. replace it with this in the SC class:
bounds {
var bounds = this.absoluteBounds;
this.getParents.do({ |parent|
(parent.tryPerform(\relativeOrigin) == true).if({
bounds = bounds.moveBy(parent.bounds.left.neg, parent.bounds.top.neg)
}, {
^bounds
});
});
^bounds
}
Maybe should be a primitive, but to lazy and rushed to do that now. Seems to work: The unit tests pass and the examples all seem to work.
Any reason not to commit?
S.
_______________________________________________
Sc-devel mailing list