Article:		Adding Spit and Polish to Your Cocoa App
Subject:		my zooming broke somewhere in devp't
Date:		2002-06-22 09:50:52
From:		psheldon
I may have extreme confusion isolating where the mistake is. I've gotten to page 5 of spit and polish and noticed this error in my zooming. I don't know whether revision control notions I heard 20 years ago have ever been refined, but I sure know my revisions were out of control, as you will see. Mike Beam's image app from both working with bitmaps 1 and 2 did zoom right. In particular, Mike's image doesn't distort on my drag of lower right corner window reshaper, mine does. Michele suggested more code for dragging in working with bitmaps article 1. For some reason, I put this in a folder for working with bitmaps article 2. Since I chose to put it in #2, I am not sure whether I added Michele's code to article 2's code or article 1's. I did working wth bitmaps article 3 on top of that revision wherein I first observed that zooming broke. Here's what happens : (at first glance impressions) At 100% my image is "right". I zoom down to 50% and I see (at least) two jumps of 50% but things settle down to about three jumps netting about an 8 times rescaling. I had the impression there might have been both horizontal and vertical rescalings in time sequence. I don't know how to slow down the graphics of os x so my brain can follow how many jumps there are in this "first glance set of impressions". Steve Jobs did genie with slow motion; I can't. Isolation choice : Since Michele's drag code is older than the stuff I build on top of it, it will have less to search amongst than code build on top of it. I can use debugger and step through slow graphics changes. scaleimageto's [[self window] zoom:nil] line called windowwillusestandardframe though, somehow, I couldn't step into windowwillusestandardframe. Passing through gave no overkill zoom on 50% from 100%. It, however, returned standard frame to something else that resized the window. But, recall, I observed that dragging the lower right corner to resize the "containing" window also resized the image. That could have compounded the zooming, you see. Candidate methodology : How do I find that something else called? I don't know how, other than flagging all methods in debugger to see "finer resolution" (of calls) on that scaleimageto's [[self window] zoom:nil] line. This methodology is bad on two counts. It is both highly inefficient, forcing slow stepping through of everything irrelevant, and might miss things called other than in my code, eg. in the frameworks.

Showing messages 1 through 5 of 5.

• my zooming broke somewhere in devp't
  2002-06-25 04:09:19  michele [View]
  
  
  Hello Paul,
  
  You cannot use my code with Mike's code, it brings conflicts.
  
  Otherwise, I tell you again (I think I've already done it) how you can see some outputs from your code.
  
  Use NSLog.
  
  The code for NSLog must be put after all variables' declarations, otherwise you'll get errors at compile time.
  
  So, when you want to see what happens during willUsesStandardFrame, put inside the code something like this, assuming that myWindow is the window you want info from:
  
  NSLog(@"Info about myWindow: %g, %g", [myWindow frame].size.width, [myWindow frame].size.height);
  
  It gives you the width and size of the window at the time the runtime system calls this line of code.
  
  You can put NSLog about what you want throughout your code. Very useful when you cannot access to info through the debugger, what happens with the window willuseStandardFrame because it is called repeatedly or when you invoke something like windowWillBecomeKey, because that debugger's window that becomes key.
  
  For other types of methods, put breaks into your code with an NSLog like this:
  
  NSLog(@"Enter myMethod");
  
  so you can trace the code and run your app with debugger and then you will understand why mixing both codes (Mike's and mine) makes no sense.
  
  Hope this helps.
  
  Michèle
• NSLog experiments #1
  2002-06-27 22:00:10  psheldon [View]
  
  
  I.
  
  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.
  
  II.
  
  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.
  
  III.
  
  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.
  
  IV.
  
  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.
  
  V.
  
  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.
  
  VI.
  
  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.
  
  VII.
  
  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!
  
  VIII.
  
  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.
  
  
• NSLog experiments #2
  2002-06-29 08:36:54  psheldon [View]
  
  
  I found myView = [[self window] contentview] did not track the size of the image on changing the zoom. As I said before, it seemed to track on dragging the corner .
  
  I put a breakpoint in drawRect just at the entrance . Thread1 showed a history of greyed calls that weren't in my source . One of these object calls associated with lower right corner dragging was something like resize titled window . I couldn't put breakpoints at this call to see if it was called on the faulty zoom.
  
  I still can't fathom what in Michele's code makes the zoom go wierd though I still think it is related to the image size tracking the window size , but it is necessary for me to go in the dark so I can appreciate when the light comes in the column.
• recoded on top of Mike's code, strange zooming and dragging
  2002-06-27 14:56:13  psheldon [View]
  
  
  I lost the zoom correctness in the mixed code, so now I have something to diagnose with NSLog. The zoom does work correctly with my rebuild on top of Mike's code. I thought I would need a review but I didn't feel hot about trying to write about the column, so the rebuild forced this review.
  
  I noted something serendipitously.
  
  The dock wouldn't drag to to open a file when I built on top of his code. It wouldn't, that is, until I dragged a file to open on the application icon in the finder. Thereafter, dragging onto the dock worked.
  
  Then I observed the code on top of yours had the same sort of enabling of dragging onto dock happen.
  
  So, I got strange intermittently working zooming in build upon Michele's dragging and strange enabling of new drag opening in both "build upon's".
  
  Now going to see if I can get NSLog wisdom.
  
  
• mixing code sense or no sense, thanks
  2002-06-26 22:23:38  psheldon [View]
  
  
  I continued Mike's column and started putting old breaks at various places to see where the zooming broke. Somehow the zooming stopped being broken and I worried that I would be considered having worried for nothing in my post because I lost the evidence that the mix didn't work.
  Now you say mixing makes no sense and I worry less about worrying.
  I need to get some sleep first before I experiment with NSLog, because the zooming seems to have fixed itself, somehow. I am frustrated like a guy who brings his car to a mechanic and then it works.
  Thank you Mich`ele.