In addition, does your code have to be in initWithFrame:? There's also awakeFromNib, at which point your view will have its frame set, if that's what you're depending on. And if it is frame dependent, what happens when the frame changes? ________________________________________ From: [email protected] [[email protected]] on behalf of Quincey Morris [[email protected]] Sent: Wednesday, December 24, 2014 8:26 PM To: N!K Cc: [email protected] Subject: Re: initWithFrame fails
On Dec 24, 2014, at 19:30 , N!K <[email protected]<mailto:[email protected]>> wrote: Thank you all for explaining what’s going on. I looked up initWithCoder; it is not suitable for my usage. I have tried again, adding a custom view assigned to class StretchView.* Still no luck, initWiithFrame is ignored. Again, strokeRect puts on a colored frame, but no Bezier path appears. If both icons, View (system supplied) and StretchView (my addition), are assigned to class StretchView, both get the frame but no path. Note that both icons are blue, so shouldn’t both get to initWithFrame? Please refer to the ScreenShot from .xib below. A further question: Would it be worthwhile to get rid of the (system) View? If so, how? Deleting StretchView from both Class assignments in the Inspector did not remove or disconnect them. Framed views remained the same. You're dealing with at least three issues here, and you’re not going to get anywhere until you disentangle them. 1. The view that’s immediately below the window in the view hierarchy is the window’s content view. You shouldn’t be trying to customize this view — treat it merely as the parent of all your views — and you certainly cannot delete it. 2. Since views with your custom class are drawing something (the frame), you know that the view exists and is using the correct override of drawRect:. If nothing else is drawing, that’s a bug in your code. Given the circumstances, that might be because some required initialization of drawing parameters isn’t happening, so there’s no point in even trying to chase this down while you still have an initialization issue. 3. You have an initialization problem. It’s vital that you diagnose this *before* you go chasing other problems. As Roland said, you should start by working out *which* init… method is being called, by providing overrides in your custom class and using breakpoints or logging to find out which one(s) are called. Again as Roland said, you should override ‘init’, ‘initWithCoder:’ and ‘initWithFrame:’. It’s not important what your overrides *do*, at this stage, only important to know which of them is being called. View initialization in Cocoa isn’t broken, we’d actually notice if it was. If no init method is apparently being called, then you’ve done something wrong. It could be something simple (like spelling the method name ‘initwithFrame:’) or something more subtle, but I guarantee you that your method isn’t failing to be called because Cocoa is doing something wrong. Once you accept that premise, you’ll be closer to a solution. It’s also worth considering how you know that ‘initWithFrame:’ isn’t being called. Debugger? Logging? One potential issue is that your CVone window is apparently in your main menu NIB file, which is actually a fairly bad place for it to be (though Apple’s templates for a single-window app do put it there). If it’s there, and you fail to *un*check the window’s “visible at launch” flag, the window and its view may be created much earlier in the app startup process than you expect. This may be contributing to the confusion. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
