<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Here's a piece of code I use a lot, particularly when I'm wrestling with UI annoyances that I can't seem to get quite straight:<div><br></div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);">// useful debugging method - send it a view and it will log all subviews</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);">// can be called from the debugger</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">- (<span style="color: #bb2ca2">void</span>) viewAllSubviews:(<span style="color: #703daa">UIView</span> *) topView Indent:(<span style="color: #703daa">NSString</span> *) indent {</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #bb2ca2">for</span> (<span style="color: #703daa">UIView</span> * theView <span style="color: #bb2ca2">in</span> [topView <span style="color: #3d1d81">subviews</span>]){</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #78492a">NSLog</span>(<span style="color: #d12f1b">@"%@%@"</span>, indent, theView);</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #bb2ca2">if</span> ([theView <span style="color: #3d1d81">subviews</span>] != <span style="color: #bb2ca2">nil</span>)</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space:pre"> </span>[<span style="color: #bb2ca2">self</span> <span style="color: #31595d">viewAllSubviews</span>:theView <span style="color: #31595d">Indent</span>: [<span style="color: #703daa">NSString</span> <span style="color: #3d1d81">stringWithFormat</span>:<span style="color: #d12f1b">@"%@ "</span>,indent]];</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">}</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">I throw this in my AppDelegate so I can call it from anywhere. For the first parameter, just give it a parent view, and it will dump out indented all the subviews. Usage is (from the debugger):</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">po [appDelegate viewAllSubviews:rootViewController.view Indent:@" "];</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">You can replace any parent view for rootViewController.view, and use whatever number of spaces you want to indent. </div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">I breakpoint and clear the console, and call it from the debugger, select all then copy and paste into a BBEdit window (or any text window). It displays a nice tree of my subviews and displays which frames are where, etc., better than stepping through them all.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">Another good tip, is that when the impossible is happening, your assumptions are wrong. The other day one of my colleagues spent a day on a nasty bug where he was moving a view around in response to a gesture. He saw the frame coordinates change in the debugger, but the view stayed in the same spot! Turns out he was changing the coordinates in a thread, and it needed to be done on the main thread (because it was graphics-related), but it's a good example of where the impossible (a view visibly in one place, but it's frame coordinates indicating another) is happening.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;">-Owen</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;"><br></div><div><div>On Jun 18, 2014, at 12:24 PM, John Shockey <<a href="mailto:john@johncshockey.com">john@johncshockey.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Owen,<br><br>Thanks.<br><br>I don't know how many folks are on this list. I don't think the ones<br>I've heard from today need this, but here's a list of debugging tips.<br><br>If it's an easy bug, just do whatever works. But if you're stuck,<br>consider:<br><br>1. The most important debugging tool is your brain.<br><br>2. Look hard at all the information you gather. Don't worry so much<br>about immediately finding the bug. Just look for anything that isn't<br>what you expected. Try to understand it, and you may find the bug shows<br>itself in the process. (That was the solution for today's bug.)<br><br>3. Try single stepping through your code. I often do this with new code,<br>especially if it's at all complicated, even if no bugs have shown up.<br>While stepping, follow rules 1 and 2.<br><br>4. If an API call doesn't behave the way you expect, don't be too quick<br>to decide it's a bug in the API. Think as if you were implementing that<br>API -- what information would you have available, and how could you make<br>it work?<br><br>5. Multi-threading issues have their own rules. Treat them like a math<br>problem and try to prove you code correct. Alternatively, treat it as a<br>puzzle and look for an exception. This is more theoretical than most<br>debugging. Multi-threading issues are difficult!<br><br>6. If a bug is really hard to reproduce (see especially #5), don't give<br>up easily when it finally occurs. I've been known to leave my debugger<br>stopped on a bug for a day. It's slow, but if it takes you days to make<br>it happen it's often worth it.<br><br><br>Anyone else have any favorites?<br><br>John<br></blockquote></div><br></div></body></html>