Skip to main content

What does the origin control do in interface builder?



In interface builder there is a control in the struts and springs inspector that is labeled origin. What does this do and why does changing it for one object change it for ALL objects?





Origin Control





As far as I can tell it doesn't have any real effect on the frame rectangle origin as the name implies. Let me explain:





Selecting a UILabel and changing the origin to be at the top right as in the photo above puts the frame origin at the point (280,11). However, in code, when you actually ask the frame for it's origin it is given as (211,11) which corresponds to the top left corner of the frame. Therefore, changing the frame origin in interface builder appears to do absolutely nothing! What is going on here?!


Comments

  1. It does nothing unless you’re editing the fields immediately adjacent to it. You’ll note that the X and Y coordinates change depending on the anchor point you select for it; that’s meant to make it easier for you to align the object by its center or edge.

    The reason it changes for all objects is that it doesn’t actually affect anything about the object itself; the “real” coordinate system remains the same regardless of the displayed X and Y values there.

    On OS X, as Nathan says, the coordinate system has its origin at the bottom left and its coordinates increase up and to the right; on iOS, the origin is at the top left, and its coordinates increase to the bottom and right.

    ReplyDelete
  2. i don't now the exact answer but i think that it has to do with the origin code you've set for that object like (just a example)

    - (void) Button {

    CGRect frame = button.frame;
    frame.origin.x = 500; // new x coordinate
    frame.origin.y = 500; // new y coordinate
    button.frame = frame;
    }


    And maybe there is a way to set the frame.origin to a setting that would connect it to the origin tool in InterFace Builder

    https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html


    Cocoa uses a Cartesian coordinate system as its basic model for
    specifying coordinates. The origin in this system is located in the
    lower-left corner of the current drawing space, with positive values
    extending along the axes up and to the right of the origin point. The
    root origin for the entire system is located in the lower-left corner
    of the screen containing the menu bar.

    If you were forced to draw all your content in screen coordinates—the
    coordinate system whose origin is located at the lower-left corner of
    the computer’s primary screen—your code would be quite complex. To
    simplify things, Cocoa sets up a local coordinate system whose origin
    is equal to the origin of the window or view that is about to draw.
    Subsequent drawing calls inside the window or view take place relative
    to this local coordinate system. Once the code finishes drawing, Cocoa
    and the underlying graphics system convert coordinates in the local
    coordinates back to screen coordinates so that the content can be
    composited with content from other applications and sent to the
    graphics hardware.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex