I'm trying to extend the NameAndPassword code sample so that the secure text fields run authentication action on return key press (currently the authentication only works if the button is pressed through the buttonPressed action).
I tried various options - creating a xib file along with ViewController to replace the existing nib file, but in such case I can't create a connection between the xib custom view and the IBOutlet that was connected to the view in the nib file before I removed it.
I also tried connecting the existing secure password field from the nib file to an App Delegate I created myself, but it doesn't want to work either - I control-drag the textfield to the appdelegate.h interface section but no lines show up.
I know this sample is very outdated now - my question is, how can I create custom actions on these views or how to recreate this project on a fresh surface?
IIRC you can't connect target-action on custom views. It only works with Apple-provided views and subclasses thereof (so if your view was a subclass of NSControl, it would work). However, you can always call setTarget: and setAction on your view in the awakeFromNib (or equivalent) method of whatever object owns the NIB.
If your class is already a subclass of another Apple-class that supports target/action, there is probably a syntax error somewhere in your code, or an #if/#ifdef or the like that makes the Interface Builder part of Xcode unable to correctly parse your class. In that case it often leaves it out, and you get none of its IBOutlets listed.
Related
I just started working on an OSX application, first time in objective-c. I need to make a window that will display all the network interfaces available on the computer.
So far
I have an AppDelegate that pretty much does nothing
I have set the Main nib file base name to my main window, which is a xib, header and implementation file
I made my xib window inherit from my class and added the outlets I needed using right-click drag (worked well, I assumed I was correct until then)
The issue
I can't seem either override or bind the load event of the window, where I want to load the text in my label.
I've seen some people use a NSWindowController, but I don't think I need this.
My question
Is it required to have a NSWindowController PLUS a NSWindow class? I feel there are too many files for a single window. I have the xib and two .h/.m files... If it's not required, how can I get notified when the window loads?
The question wether you need NSWindowController(s) or not depends on the complexity of your application.
If your app is only a small utility using a single window, you might get away with setting up your UI in MainMenu.xib and connect it to some IBOutlets in your AppDelegate.
But the above approach gets messy soon when your app becomes more complex. To tame that complexity, you can create dedicated NSWindowController classes (e.g. one per window). Those window controllers could manage a hierarchy of child NSViewControllers to further split up your complexity.
If it's not required, how can I get notified when the window loads?
The default Xcode template should have created an AppDelegate.m file. You can add code to initialize your UI in
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
At this point the window has been fully loaded and
#property (weak) IBOutlet NSWindow *window;
should point to your window instance.
I am playing around with the default XCode template for a cocoa application. By default it has a MainMenu.xib with a window and a menu -- awesome.
I intend to build up my views/subviews in code, so I then create a RootView : NSView and a RootViewController : NSViewController, and bind them up in IB so that my base view in that window is my RootView, controlled by my RootViewController.
Enter my question -- How do I do the same to have a RootWindowController bound to the NSWindow? I had assumed File Owner was the trick, but it's set to NSApplication, which I think is correct. The main goal of NSWindowController in my case is to manage the toolbar based on NSNotifications fired from other services -- is this even the correct design here? I don't think I can do this from my RootViewController since I don't have a window reference, but is that where I should do it instead?
Many times, the application delegate is used as the main/central controller for a non-document-based application. This is a good place. This can be an NSWindowController instance if you like. You can just do away with the existing window in your nib.
Helpful information from the NSWindowController API reference:
You should create a subclass of NSWindowController when you want to augment the default behavior, such as to give the window a custom title or to perform some setup tasks before the window is loaded. In your class’s initialization method, be sure to invoke on super either one of the initWithWindowNibName:... initializers or the initWithWindow: initializer. Which one depends on whether the window object originates in a nib file or is programmatically created.
But if it were me, I wouldn't bother going the NSWindowController route; I'd just add this logic to my app controller (and set it as the app delegate) since this is app-level stuff. No need to add a layer of complexity unless you've got a LOT of main-UI-updating complexity you want to compartmentalize.
I'm using XCode 4, and note that when setting up a new Cocoa Application project, you get an AppDelegate.m and .h file, as well as a .nib (.xib). Using alt-command-return, you get the 3-column editor layout, from which you can control-drag from controls to the AppDelegate.h file to create Outlets or Actions.
My question is, is it recommended to utilise these AppDelegate files to manage your interface controls ie. updating labels, acting on button presses etc. OR is it better to create an AppController class, add an object to the .xib and subclass it to AppController, modifying AppController to mange the controls? If this is the case, what are appropriate uses of AppDelegate?
I would like to say, it is just a matter of development style. What I do is use another class and change the AppDelegate to that class/view and use. Also I do not draw outlets and button on the default window. I make a view and add those as subviews to the mainWindow.
I have several XIBs following this pattern: a View Controller subclass containing a View subclass. I put my controls on that view.
Just now, I tried to add a new control to the view. I can do this, but I'm unable to connect the new control to an outlet. The assistant editor won't display the view subclass header either, though it will for a short while if I restart Xcode. Some other XIBs I have don't have the view controller object but instead have File's Owner set to a view controller subclass. They show the same problem.
Here is the Objects bar in IB:
"Matrix Editor View Controller" is a UIViewController subclass. This shows up fine in the Assistant Editor's "Counterparts" menu and I can drag from UIControls to it to create outlets & actions.
"Popup Cell View" is a UIView subclass. This is where the majority of my outlets and actions live. Previously this would show up in the Assistant Editor "Counterparts" menu and I could drag between it and my controls and the code quite happily. Now, whenever I add a new control in to this view, I can't drag from the Popup Cell View object to the new control, nor can I drag from the new control to the Assistant Editor window if it's showing the Popup Cell View header.
I recently had to upgrade to Lion (and hence Xcode 4.2.1 build 4D502); the last time I added controls to my XIBs was under Snow Leopard with the latest Xcode on that OS.
I believe that Xcode's caches or some internal state are out of whack. I have tried:
Restarting Xcode
A clean
Removing and re-adding the view subclass from the project
Deleting the DerivedData folder's contents from ~/Library/Developer/Xcode
And various combinations thereof. What else can I do to force Xcode to re-scan everything and allow me to connect up my controls to outlets?
Edit: I have noticed that I can create outlets in the View Controller for my new controls; I'm just not able to do this on the View subclass itself which is where I want them. I already have many on there. Could my new version of Xcode really be telling me that I'm not allowed to do this? Surely not. The Assistant Editor's Automatic mode changes every minute or so between two counterparts (the VC .h and .m) and four (the VC .h/.m and the View .h/.m).
Edit: I was able to connect an outlet, but only via this convoluted method:
Force the assistant editor to open my View subclass
Manually typing in an outlet for my new control
Dragging from the outlet in the assistant editor to the control itself
So something is very clearly broken. How can I fix it?
Very frustrating!
Thanks
When I have this problem, it is usually due to a mismatch in the class type somewhere. Verify that the class name of the object in you xib matched the class name in the interface and the implemetation files.
I'm a newb - I recognize this is a kludge, but hope this helps somebody. Sounds kinda sorta like the problem described above.
Suddenly, xcode refused to "insert new action outlets" into my AppDelegate.m (using control+drag, from a newly added xib element, into the class #implementation). Also, Xcode does not display that little-dark-circle next to each IBAction method in the .m file, like it used to.
Xcode allows drag of the blue-line from the 'source xib element' -- but would not show the "Insert Outlet or Action" & blue-circle-line with destination-highlight at the 'target line of insertion', in the .m file.
However, I can insert new outlet into my AppDelegate.h, using that above-described blue-line drag-method. That file is adorned with the cute little-black-circles, properly.
The kludge-around I came to was this
add 'bogus #implementation code' to the AppDelegate.h, as per:
#if 1
#implementation AppDelegate
#end
#endif
control+drag from the new xib element into/inside that #if 1 #implementation region in the .h
viola! xcode now displays the desired "Insert Action" & blue-circle-line target at the position for insertion. I can assign the method name and express whatever semantics I wish. Xcode source-editor shows a cute little-dark-circle to the left of the 'autogenerated' -(IBAction) line. For example, I added imanewxibobject as per:
#if 1
#implementation AppDelegate
- (IBAction)imanewxibobject:(id)sender {
printf("%s: hi there!\n",\_\_FUNCTION\_\_);
}
#end
#endif
(1+2)=3. Copy & paste that -(IBAction)imanewxibobject:... function into my actual AppDelegate.m (where it really belongs).
(2+2)=4. Turn that #if 1 (in the AppDelegate.h) to #if 0
(3+2)=5. recompile. Kablammo, the new UI element is alive with semantics!
I tried all: cleaning the project, deleting the files from the project, etc.
I peered into that .xib file and found it contained lots of what appears to be cross-referenced identifier indices, kinda what you may expect to see, in a file of this sort.
So I still don't have those little-dark-circles beside my -(IBAction)s -- but at least the code compiles, and I see the correct method-label string, for the Xcode Utilities->"Show Connections Inspector", with respect to the new UI element.
Anybody know how I can restore those cute little-dark-circles beside my "-(IBAction)"s? I find them very cute, and wish to have them back. I don't see any "Display cute-little-dark-circles" menu options. Bummer. Maybe in the next Xcode?
I have a Quartz Composition with a Cube, and X/Y/Z rotation inputs are published.
On Interface Builder I made a QCView and a QCPatchController with the previous Quartz Composition loaded. In QCView the Patch Controller is binded, and the rotation published ports are binded too to three NSSlider, so when I change the value of the NSSlider's then the cube rotates.
All this works fine, but I want to change the rotation values of the cube from the App Delegate on XCode. I tried to change the value of the NSSliders with IBOutlets pointing to them, but this change doesn't apply to the cube, like it does when I change the Sliders directly with my mouse.
What should I instanciate and/or how to access and change this Input_Ports.value throught the CQPatchController?
Thank you very much for reading, i really need help!
It's actually quite simple! The patch controller will accept KVC's setValue:forKeyPath: just fine. (The desired key path will probably look like patch.Input_Ports.value.)
To connect to your patch controller, you'll need to add an outlet to your app delegate. In your app delegate's .h file, add an instance variable IBOutlet NSObjectController* patchController.
IBOutlet doesn't do anything for the compiler, but it signals to Interface Builder that there's an outlet there. Once you've added that line, you'll be able to go back to Interface Builder and control-drag from your app delegate to your patch controller, thus connecting the patchController outlet to the specific instance in your .nib file.
(There is no .h file for QCPatchController, but it's a subclass of NSObjectController, so you can safely declare it as such.)