Adding Spit and Polish to Your Cocoa App
Subject:   NSLog experiments #1
Date:   2002-06-27 22:00:10
From:   psheldon
Response to: my zooming broke somewhere in devp't


I learned that stdFrame in windowWillUseStdFrame was used for the window's frame after windowWillUseStdFrame returned. That is [[self window] frame] had value stdFrame in method after method. Hence the name of method.


I tried constantly hitting enter on various fixed zoom % field values :

I noted, in contrast to code built upon MIchele's dragging stuff, that code built upon Mike's code, though the full window size was bouncing around, left width and height and actual zoom % were left constant. width and height of the image were proportional to zoom leaving image undistorted.

So, for code built upon Mike's code :

1. width and height are of something other than the enclosing window.

2. width and height and actual zoom % constancy associated with zoom % field constancy.

Only stdFrame width tracked zoom % field (proportionally), so stdFrame is not exactly the frame in which the image is caste.

In code built upon MIchele's drag modifications the image both actual zoomed and distorted on multiple hits. The image size bounced around like the window size. When I dragged the lower right hand corner of the window, Image tried to track the width height distortion of the window.


I got no information from NSLog in windowWillUseStdFrame, so, in this method, NSLog not useful to find the part of the flaw that has the image tracking the scale of the top parent window.


How can I show why the image responds to that corner drag? I first show, not why, but how it responds.

In drawRect, I both declared myView = [[self window] contentview] and placed that in place of myWindow in your NSLog code. The numbers now track both the corner drag and image zoom distortion.


With code upon Mike's, NSLog code not called showing that drawRect not hit with corner drag. I have a much clearer picture of what is going on. Now, setNeedsDisplay sets off drawRect. I found with batch find methods with setNeedsDisplay and saw all the "visible ones" to be Michele drags.


I thus find it plausible a drag on the lower right corner is a Michele drag source and destination. I might drag an apriori distorted image to a new distorted contentview, distorted by the corner drag.


To test contradiction to this hypothesis, I placed the declarations and NSLog call in each of the Michele methods containing setNeedsDisplay and didn't find these called!


Now I'm lost and giving it over for the night.

To offset the failure :

I got confidence in formatting NSLog feedback and with this confidence hypothesizing what was actually the rectangle of the image.

1 to 1 of 1
  1. NSLog experiments #2
    2002-06-29 08:36:54  psheldon [View]

1 to 1 of 1