scaleUnitSquareToSize strange behavior Scaling a UI
scaleUnitSquareToSize strange behavior Scaling a UI
- Subject: scaleUnitSquareToSize strange behavior Scaling a UI
- From: Joshua Strickon <email@hidden>
- Date: Tue, 8 Sep 2009 17:46:07 -0400
I am trying to build a ui where I have an NSView with a variety of
subviews that are programatically added from nib files similar to the
CocoaSlides demo. I need to be able to zoom in and out. Essentially
I have little boxes of cocoa controls. I have tried all sorts of
solutions with ambiguous results. It seems that when I call
scaleUnitSquareToSize there are strange results.
My first attempt was to scale the frame of the main view and then
planned on calling scaleUnitSquareToSize and have everything trickle
down. That did not work. I then started doing everything manually by
turning off autoresizing of subviews for the main view. I can scale
the frame but scaleUnitSquareTosize again causes problems on the
controls of the nib.
I also did a test of just building a window cocoa app with a nib to
confirm that I can successfully scale buttons, sliders and such and
that works. Those objects are subviews of the main window. I also
encapsulated controls in a box and it all works with
scaleUnitSquareToSize.
I found this old email thread which sounds very similar. I don't
think a solution was ever proposed though.
Any help would be appreciated.
Thanks
Josh
John,
Thanks for the insight. Regarding your statement:
"The resizing behavior pertains to the frame, and not the bounds. Once
you've scaled the bounds, if the frame changes, the view may appear to
move in unexpected ways depending on the view's own coordinate space
(it may be inverted, for example).
Is it possible to programmatically prevent this resizing behavior when
scaling and then resizing the frame to display the entire bounds of
the view ?
Thanks again,
Bob
On Feb 19, 2005, at 9:28 PM, John C. Randolph wrote:
On Feb 18, 2005, at 7:03 AM, Robert Miller wrote:
Hello,
Has anyone had in depth experience with the
'scaleUnitSquareToSize' call vs. the resulting frame size of the
receiver ? I'm working on an application that has movable /
resizable custom subviews that are also scalable. I've done some
research and have discovered some very useful examples on scaling
using the scaleUnitSquareToSize' call and understand it's use and
how the bounds rectangle of a view is affected by this call. The
call does not affect the frame rectangle as would be expected
however, I want to be able to display the entire scaled bounds in
the NSView after scaling.
The frame of a view is the view's location and size in its
superview's coordinate space. -scaleUnitSquareToSize: affects the
bounds, not the frame of a view.
I've added some code which effectively readjusts the frame
rectangle to do this. The real issue is that once a view is scaled
it seems that any subviews within that view seem to have lost their
auto resize mask. (even though diagnosis has shown that they
haven't) The behavior of subviews when a previously scaled view is
subsequently resized appears as if they have. Example. A custom
view is created and displayed, the custom view contains sub views
whose 'spring' settings include NSViewMinYMargin and
NSViewMaxXMargin which cause the subviews to 'stick' to the top
left corner of the view when the view is resized such that its
width and height are increased. After the view is scaled the
subviews no longer behave as if the previously mentioned resize
settings are in effect. (even though as previously stated the
values for resizing have not changed). In other words when the view
is resized after a scale is applied the subviews now move and no
longer stick to the top left corner. Is this some strange anomaly
with scaling and resizing mask behaviors internal to NSView. Does
my example make sense ?
The resizing behavior pertains to the frame, and not the bounds.
Once you've scaled the bounds, if the frame changes, the view may
appear to move in unexpected ways depending on the view's own
coordinate space (it may be inverted, for example).
-jcr
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden