I followed the Tutorial in Cocoa Programming For Mac OS X to create a preferences window but am returned with 2 warnings which stop it from working/opening. These are the two warrnings:
alt text http://snapplr.com/snap/varq
alt text http://snapplr.com/snap/qmxc
How can I resolve the problem?
The warnings mean the object in question doesn't (as far as the compiler knows) implement those two methods. This means either your window controller is not inheriting from the right superclass, or the pointer to the window controller is of the wrong type. It may or may not be the reason your window isn't opening, it's impossible to tell from the warnings alone.
edit: from your full code it looks like you're declaring your controller as inheriting from NSObject, instead of NSWindowController.
Just as it says, showWindow isn't defined on the PreferenceController class. In C++, this would be an error because it's statically typed and would say "method not defined", but since Objective-C is more flexible, this is only a warning. Without seeing the code, it's hard to tell what your mistake is though.
Related
I don't understand why, even on Xcode 6, I need to click on self, search the property, and only then see the value.
If the object have 100 properties it's very annoying.
I'm searching for simple solution that when I set my mouse cursor on self.someproperty,
above "someproperty" I will see the value of it, in any case, NSString, NSArray, Etc.
Thanks.
That's presumably because the "properties" you're hovering above are not really variables. They are syntactic sugar for accessor methods (that generally reference a backing instance variable, but not necessarily so). These accessor methods, the getter and setter, were either synthesized for you, or you may have manually implemented your own custom methods. For more information about declared properties, see Declared Properties discussion in Apple's Core Competencies document or Properties Encapsulate an Object's Value in the Programming with Objective-C document.
Consider the foo property below. You cannot hover over references to self.foo and see what you were expecting. But, if you hover over the instance variable (ivar) that backs the property, you may:
(As an aside, note that the reference to self.foo = ... above does not reference the foo getter method, but actually calls the setter method setFoo. So, it seems like a non-trivial exercise to have the IDE debugger recognize that by hovering over that "property" while execution is paused there, but realize you want to call the getter to see the value rather than calling the setter that line of code actually references.)
Anyway, back to the IDE, you can also twist open self, you'll see it there, too:
These techniques are imperfect (sometimes the debugger gets confused), but hopefully this illustrates the basic UI.
I gather you would like it to call the accessor method when you hover over the property name. Does that mean you also want it to call any random method that the mouse happens to hover over, too? In a purely functional language, this notion seems a little more plausible, but it seems dangerous in the procedural languages where any method could conceivably change a state variable and have some unintended consequence. I would have thought that if you contemplate a feature like this, it should require some something more affirmative action than merely hovering over it.
Anyway, if you really want this feature, file a "feature request" at http://bugreport.apple.com.
You can use the the logging functionality of lldb right in the console, it's a huge help:
In the right part of your Debug area you have the Console (that's also where all NSLog output goes to).
In the Console you can just use the command po (print object) and print to print the value of a variable.
I have two basic practical problems:
1) The first one is really stupid. I receive a message saying: "Method definition for 'aIncreasedSelection' not found, together with an "Incomplete Implementation".
Well, that is quite strange, because I don't have this method in neither my .m or .h file (and the class name is mentioned in the remark).
I used to implement this method, but I deleted it because it was redundant. In a certain way, it appears as if my Xcode project can't let go of the method...
2) The second question is also a very mysterious one. I have a couple of viewControllers in which I have put the identical same background, and the identical same buttons. It's really identical in size and position in the screen as well (I defined the pixels). For an unknown reason, when I switch between the views, one of the buttons changes very slightly its color (it is a Photoshop created button with mirror effect on the bottom, it's the mirror that becomes lighter). That is really annoying because it's supposed to be identical; when the user switches views now, he can see that there is a color difference in the button (supposed to be planted as a button in a dock, which should be identical over the entire app)...
Very frustrating as I cannot solve these small mistakes... Any ideas? Thanks!
Regarding your first problem, if you have verified that it no longer exists in your .h or .m file, try to cmd+shift+k and clean your project, then rebuild. This should update everything and in theory solve that issue for you.
As for the second problem, it sounds strange indeed. Is there any chance you could provide pictures somehow? Are you statically loading the image into similar buttons, or are you doing something differently?
Re - opening my project solved my first problem (unlike the refresh - cmd + shift + k, which didn't work). The color problem is not solved despite :-/
It was definitely a bug since I didn't change anything. It is in fact - very confusing!
Okay, I'm fairly new to Cocoa and Objective-C, and to OOP in general.
As background, I'm working on an extensible editor that stores the user's documents in a package. This of course required some "fun" to get around some issues with NSFileWrapper (i.e. a somewhat sneaky writing and loading process to avoid making NSFileWrappers for every single document within the bundle). The solution I arrived at was to essentially treat my NSDocument subclass as just a shell -- use it to make the folder for the bundle, and then pass off writing the actual content of the document to other methods.
Unfortunately, at some point I seem to have completely screwed the pooch. I don't know how this happened, but closing the document window no longer releases the document. The document object doesn't seem to receive a "close" message -- or any related messages -- even though the window closes successfully.
The end result is that if I start my app, create a new document, save it, then close it, and try to reopen it, the document window never appears. With some creative subclassing and NSLogging, I managed to figure out that the document object was still in memory, and still attached to the NSDocumentController instance, and so trying to open the document never got past the NSDocumentController's "hmm, currently have that one open" check.
I did have an NSWindowController and NSDocumentController instance, but I've purged them from my project completely. I've overridden nearly every method for NSDocument trying to find out where the issue is. So far as I know, my Interface Builder bindings are all correct -- "Close" in the main menu is attached to performClose: of the First Responder, etc, and I've tried with fresh unsullied MainMenu and Document xibs as well.
I thought that it might be something strange with my bundle writing code, so I basically deleted it all and started from scratch, but that didn't seem to work. I took out my -init method overrides, and that didn't help either. I don't have the source of any simple document apps here, so I didn't try the next logical step (to substitute known-working code for mine in the readFromUrl and writeToUrl methods).
I've had this problem for about sixteen hours of uninterrupted troubleshooting now, and needless to say, I'm at the end of my rope. If I can't figure it out, I guess I'm going to try the project from scratch with a lot more code and intensity based around the bundle-document mess.
Hard to tell without code but I would suggest sending:
closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
... to the document controller and then looking at the controller as it is passed to the delegate to see how its state changes.
If the controller closes the document when you send the explicit message then your problem is with the binding to the window.
Does this control have a name? Or is it just a bunch of simple controls merged together? If so, what controls are they?
http://img8.imageshack.us/img8/3002/picture2xrb.png
It looks like an NSTableView with an a custom cell type and no column header. Have a look at the documentation for NSTableView's tableView:dataCellForTableColumn:row:. For columns which have the same type for all rows you may also set the cell class in interface builder.
I doubt the search box is part of the same control.
You could open the Application's Nib file to see what is in there. Look inside the application bundle. If the application is called Example then you should be able to find the Nib at Example.app/Contents/Resources/English.lproj/MainMenu.nib.
The best tool for investigating this is fscript, specifically FScriptAnywhere which will let you determine the class and much other information about any visual element of any Cocoa program (and do a lot of other interesting things with Cocoa programs).
In addition to what toholio said, an easy way to get the look and feel of the bottom button bar is with BWToolkit.
I followed Chapter 8 of Hillegass to implement the RaiseMan application there.
Then I decided to follow the same process to implement the code for an exercise in a Cocoa programming class that I am taking, but I got the following very cryptic error message after building and running.
Cannot create BOOL from object <_NSControllerObjectProxy: 0x100460e30> of class _NSControllerObjectProxy
I have no idea what this error message means. Doing a Google search brought up some hits, but their remedies seemed to be to do things that I was already doing.
I stared at all the connections and assignments that I made in Interface Builder and nothing looks obviously wrong.
So I went into the debugger and set a breakpoint inside the init method of the MyDocument class and it is being called twice. How could that happen? What should I be looking for that would make the init method be called twice? The stack trace shows that init is called by system functions that we did not write ourselves.
For comparison, I went back to the project that follows Chapter 8 of Hillegass and set a breakpoint inside the init method of the MyDocument class, and it is being called once ( which is what one would expect ).
Cannot create BOOL from object <_NSControllerObjectProxy: 0x100460e30> of class _NSControllerObjectProxy
It appears you've bound a BOOL property to a controller, and not specified a model key path. Most probably, you bound one of the Cocoa view classes' built-in bindings, such as enabled or editable.
Look through your nib for views whose enabled or editable you've bound, and make sure they are all bound to the correct model key path.
I just ran into this myself. And then I remembered seeing something odd before, whose significance hadn't struck me at the time. Which is that in my XIB file, there was a "My Document" object, in addition to the "File's Owner" object (which is what actually represents the document in the XIB file). I have no idea how it got there, but I deleted it in IB, recompiled, and presto, [MyDocument init] only gets called once now.