On Oct 25, 2012, at 18:09 , Peter Teeson <ptee...@me.com> wrote: > Where do I go from here?
You're trying to solve too much at one time. The issue is the apparent non-appearance of one of the views, so the issue of where the setMyColor action goes is merely a distraction. 'initWithFrame', 'awakeFromNib' and 'drawRect:' are also distractions, though they may become relevant once you learn where the 2nd view went. In the ordinary course of events, there are three straightforward reasons why a view might not appear: 1. It's hidden. (Likely not a factor in your case, but you shouldn't make assumptions.) 2. It's got the wrong frame, so it's outside the visible rect of the window or an enclosing view. 3. It's underneath something opaque, such as the other custom view. It's absolutely useless *reasoning* about these matters (reasoning has already told you both views *should* be visible). You need to *examine* their state, preferably in the debugger. To do this, you have to make sure you don't waste your time watching what happens at initialization or awakeFromNib time, because the window and view state can change later. You need to examine the state at the time you see the window's faulty appearance. One way to do this is to set a breakpoint on one of your menu item action methods, and when your window is finished appearing on screen, initiate the menu action and trigger the breakpoint. (If this is an action method in your document subclass, so much the better, because you'll have the 2 ivars easily available to you.) Then check: -- the ivar values, to make sure both views still exist -- the "isHidden" property of both views -- the frame of both views, making sure you don't mistake the coordinate systems you're dealing with -- the view hierarchy (superviews), to check that both views actually have a common ancestor, and that there's no other view in the way My guess is that the problem is something like an inadvertent use of auto-layout, so that although you may have placed the views in IB they actually are configured to center themselves in their superview, meaning one gets moved on top of the other. (This could explain the "bizarre" color behavior you noted in your most recent post. It could also perhaps explain why the results were different in your old state-restored window vs. a window created with Command-N.) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
