my zooming broke somewhere in devp't

Article:		Adding Spit and Polish to Your Cocoa App
Subject:		my zooming broke somewhere in devp't
Date:		2002-06-25 04:09:19
From:		michele
Response to: my zooming broke somewhere in devp't
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

Showing messages 1 through 4 of 4.

NSLog experiments #1
2002-06-27 22:00:10 psheldon [Reply | 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 [Reply | 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 [Reply | 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 [Reply | 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.