[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] relativeOrigin...

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.
- this has one failure, and one example where only humans can tell that it failed.

though I see that mr ctrl-t has managed to fix several of the recent ones !

unfortunately I can no longer run UnitTest.testAll because there are so many and the app seems to be doing illogical things.

this commit also adds absoluteBounds as a getProperty method

--- SCView.M    (revision 7296)
+++ SCView.M    (working copy)
@@ -890,6 +890,19 @@
             SetFloat(slots+3, mBounds.height);
             return errNone;
+       if (strcmp(name, "absoluteBounds")==0) {
+                       SCRect drawBounds;
+            if (!(isKindOfSlot(slot, s_rect->u.classobj))) {
+                return errWrongType;
+            }
+                       drawBounds = mLayout.bounds;
+            PyrSlot *slots = slot->uo->slots;
+            SetFloat(slots+0, drawBounds.x);
+            SetFloat(slots+1, drawBounds.y);
+            SetFloat(slots+2, drawBounds.width);
+            SetFloat(slots+3, drawBounds.height);
+                       return errNone;
+       }
        if (strcmp(name, "visible")==0) {
                 SetBool(slot, mVisible);
                return errNone;
@@ -948,7 +961,14 @@
 SCContainerView::SCContainerView(SCContainerView *inParent, PyrObject* inObj, SCRect inBounds)
        : SCView(inParent, inObj, inBounds), mChildren(0), mNumChildren(0), mRelativeOrigin(false)
-       mLayout.bounds = mBounds;
+       mLayout.bounds = inBounds;
+       if(mParent ){
+               if(mParent->relativeOrigin()){
+                       SCRect pBounds = mParent->getDrawBounds(); // or jsut absolute frame bounds ?
+                       mLayout.bounds.x = inBounds.x + pBounds.x;
+                       mLayout.bounds.y = inBounds.y + pBounds.y;
+               }
+       }

I think this is the bug its fixing:


var w,c,d,s,t,bounds,absoluteBounds;

w = SCWindow.new("TestSCCompositeView:test_absoluteBounds white comp should be in the middle of blue comp");

c = SCCompositeView(w,Rect(30,30,300,300));

c.relativeOrigin = true;

c.background = "" style="color: #0000bf">Color.blue;

t = GUI.compositeView.new(c,Rect(100,100,100,100));

t.relativeOrigin = false;

t.background = "" style="color: #0000bf">Color.white;


// absoluteBounds gotten directly from the view's internals

absoluteBounds = t.absoluteBounds;

// should be the same as this:

bounds = t.bounds;

t.getParents.detect({ |parent|

(parent.tryPerform(\relativeOrigin) == true).if({

bounds = bounds.moveBy(parent.bounds.left, parent.bounds.top);


}, {




this.assertEquals( absoluteBounds , bounds,".absoluteBounds from the view should be same as the logical calculated bounds for compositeView");

this.assertEquals(absoluteBounds , Rect(130,130,100,100),"bounds should be 130,130,100,100 for compositeView");

On Feb 9, 2008 1:18 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
I've committed this. Given that there's still some mucking about going on in the GUI stuff I figured best to have this in so people can text against it before the new RC.