It's called only once, like viewDidLoad
It's called right before viewWillAppear. So it's called after the UIViewController navigationController is no longer empty.
Basically I want to set things up programatically stuffs for UIViewController. However, I want navigationController property to already exist. Also I want the whole thing to be called only once.
I'm not super-familiar with view lifecycles in iOS but if by some chance there is not a method that fits your description and you really do need to have such an event, you could always use a call back combined with a property, ie
- (void)viewWillAppear:(BOOL)animated {
if (!self.specialMethodHasBeenCalled) { [self doSpecialMethod]; }
// other viewWillAppear stuff to do every time
}
- (void)specialMethod {
// do stuff
self.specialMethodHasBeenCalled = YES;
}
Might need to do some more stuff for thread safety, but this is just a hacky solution.
Related
I have a window that I am creating based off of clicking a row in a Tableview, instantiated like such:
HKLUserProfileController *userProfileController = [[HKLUserProfileController alloc] initWithNibName:#"HKLUserProfileController" bundle:nil];
_wc =[[NSWindowController alloc] initWithWindowNibName:#"HKLProfileWindowController"];
[_wc.window.contentView addSubview:userProfileController.view];
// other extraneous stuff here
[_wc showWindow:self];
if([_wc.window canBecomeKeyWindow]) {
[_wc.window makeMainWindow];
[NSApp activateIgnoringOtherApps:YES];
[self makeKeyAndOrderFront:self];
}
This works, but I cannot seem to get the window to become the main/key/front window. I've tried:
... from this place where I am creating the WindowController, and also from inside viewDidLoad/loadView of the NSViewController whose View was added to the Window. No dice. (this is my ultimate goal here, so if you see something obvious i'm missing, please point it out).
So I realized that I should be trying to do this in the subclass of the WindowController itself... so I thought to put it in windowDidLoad, but no result. I set some breakpoints, and tried the other logical init methods, and to my surprise, NONE of them fire at all.
#implementation HKLProfileWindowController
- (void)windowDidLoad {
[super windowDidLoad];
// breakpoint here
}
-(void)awakeFromNib {
// breakpoint here
}
- (id)init {
// breakpoint here
self = [super init];
if (self) {
// breakpoint here
}
return self;
}
#end
My xib is connected as an Outlet / Delegate to my File's Owner properly, as far as I can tell. This is leading me to believe this is the root of the problem, but for the life of me, I can't figure out what is the issue...
Thanks...
EDIT
I realize what is happening with the keyWindow - because it's coming from shouldSelectRow in the TableView, it IS becoming key on mouseDown events, but the first window - which holds the TableView - is becoming key again on mouseUp events... which is maddening!
Will search for solutions to that, but open to comments here!
(still can't figure out why the init methods are not firing though...
You use NSWindowController in your alloc/init line and you expect it to become an HKLProfileWindowController instance? Why?
You also need the File's Owner custom class set to HKLProfileWindowController but there's no reason to expect that's sufficient to get an HKLProfileWindowController instance when you ask for an NSWindowController. What you get is an NSWindowController and none of the subclass code is used.
I'll delete this answer if your code is from before you implemented the HKLProfileWindowController class, but given what you have pasted here, that's why your breakpoints don't get hit.
-(void)Complete{
CM(#"complete");
[BNUtilitiesQuick UtilitiesQuick].startForm=0;
[self.view removeFromSuperview]; //This remove superView and the new view will be listNewController
[self setSearchLocationWhenChangeSearchBar];
if([self.searchListTemp isEqualToString:[cachedProperties singleton].searchList] && [self.searchLocationTemp isEqualToString:[cachedProperties singleton].searchLocation]){
CLog(#"Don't do anything");
}
else{
...
//Blablabla
//[Timer searchCriteriaChanged];
}
[[BNUtilitiesQuick ListController] viewWillAppear:true];//It's not called if I don't do this
}
Part of me feel that it should be called automatically. Somehow I must have done something wrong when it's not called.
Obviously I don't want things to get called twice either.
So I ended up calling them explicitly. Somehow it feels wrong. Am I wrong?
viewWillAppear is declared in UIViewController.h , it gets called automatically every time the view is about to appear. at some point you have to use super in your implementation.that could be the reason why its not called automatically, because your BNUtilitiesQuick is not a class of UIViewController
If you want some action to happen just before your view disappears, you can write your code in the viewWillDisappear method. This method notifies the view controller that its view is about to be removed from a view hierarchy.
- (void)viewWillDisappear:(BOOL)animated{}
Okay so I feel like there's something obvious I'm missing in this question. I've used makeFirstResponder throughout my code to move from textField 1 to 2, 2 to 3, etc. That seems to work as I want it to, yet when the new view is loaded, I want the cursor to be in textField1, and yet the following code does not place the cursor in textField1 upon load.
- (void) awakeFromNib{
[[[self view] window] makeFirstResponder:textField1];
}
I also tried setInitialFirstResponder, and that didn't have any effect either (I don't even think that would be right.) So, is it because it is in the awakeFromNib method? Can anyone tell me what I'm missing? Thanks in advance.
EDIT - My solution was differed slightly from the accepted answer so I thought I'd post my implementation. Because the view I wanted to set the first responder for was a subview added later (think the second screen of an application wizard), I simply added a setCursorToFirstTextField method:
- (void) setCursorToFirstTextField {
[[[self view] window] makeFirstResponder:textField1];
}
And made sure to call it after I had added the subview to the custom view on the original window.
Yes, you're right about the problem being the location of the method in awakeFromNib. If you log [self.view window] in your awakeFromNib, you'll see that it's NULL. I don't know how exactly you have things set up, but I'm guessing (if this relates to your WizardController question) that you're doing an alloc initWithNibName:bundle: in another class to create your view controller and then adding that controller's view to the view hierarchy. If you throw some logs in there, it will show you that awakeFromNib in the controller class is called after the alloc init, but before the view is added as a subview, so there is no window at that time. The way I got around this problem was to create a setup method in the view controller class (with the makeFirstResponder code in it), and call it from the class where you create the controller after you add it as a subview.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
self.wizard = [[WizardController alloc] initWithNibName:#"WizardController" bundle:nil];
[self.window.contentView addSubview:wizard.view];
[self.wizard doSetup];
}
I was just curious weather it is a good idea to call viewdidload a method like in an ibaction or something of that kind.
thanks,
TC
Check:
UIViewController Class Reference
viewDidLoad
This method is called after the view
controller has loaded its associated
views into memory. This method is
called regardless of whether the views
were stored in a nib file or created
programmatically in the loadView
method. This method is most commonly
used to perform additional
initialization steps on views that are
loaded from nib files.
The viewDidLoad method is automatically triggered.
Generally there is no need to trigger viewDidLoad yourself.
If you need to run specific code both after loading and button-click, do this:
- (void)viewDidLoad {
[self specificFunction];
}
- (IBAction)theButton:(id)sender {
[self specificFunction];
}
- (void)specificFunction {
// This code wil run after the view has been loaded
// and when the user clicks the button
}
The disadvantage of calling ViewDidLoad is , the superclass methods would be called as it has [super viewDidLoad], which is not a good idea .
It's better to have a separate methods and call them whenever necessary .
I am having some problems implementing QuickLook functionality from a table in an NSView. The limited documentation on QuickLook really doesn't help at all.
After reading through the Apple Docs (which are geared heavily towards custom generators and plugins), I ended up looking at the QuickLookDownloader sample code. This code is based upon a document-based application, but appears to be the right method for me (after all it is Apple's code and it does work in their project).
In my implementation I can get the QuickLook panel to show up just fine, and I can dismiss it just as easy. However, the panel itself never calls the delegate methods from within my NSViewController. As a result I never even get to displaying objects, just the wording "No items selected". And I am stumped.
I tried calling a setDelegate, but get warned about impending doom if I continue down that route...
[QL] QLError(): -[QLPreviewPanel setDelegate:] called while the panel has no controller - Fix this or this will raise soon.
See comments in QLPreviewPanel.h for -acceptsPreviewPanelControl:/-beginPreviewPanelControl:/-endPreviewPanelControl:.
And then doom happens anyway with a dealloc when trying to respond to one of the delegate methods.
And yes I did read the header which confirms that I should be setting the delegate after I won the panel (see code below).
So here's my code, which pretty much matches the sample code with the exception of a) where I get my data from (I get it from an NSArrayController) and the b) where I get my preview item from (mine comes directly from my model object - or should anyway)
#interface MyViewController : NSViewController
<QLPreviewPanelDataSource, QLPreviewPanelDelegate> {
QLPreviewPanel * previewPanel;
NSArrayController * myArrayController;
NSTableView * myTable;
// [...] Other instance vars
}
#implementation MyViewController
// [...] all the other methods, init, dealloc etc...
-(IBAction)togglePreviewPanel:(id)previewPanel {
if ([QLPreviewPanel sharedPreviewPanelExists] &&
[[QLPreviewPanel sharedPreviewPanel] isVisible])
{
[[QLPreviewPanel sharedPreviewPanel] orderOut:nil];
}
else
{
[[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil];
}
}
-(BOOL)acceptsPreviewPanelControl:(QLPreviewPanel *)panel
{
return YES;
}
// This document is now responsible of the preview panel.
// It is allowed to set the delegate, data source and refresh panel.
-(void)beginPreviewPanelControl:(QLPreviewPanel *)panel
{
if (DEBUG) NSLog(#"QuickLook panel control did BEGIN");
previewPanel = [panel retain];
panel.delegate = self;
panel.dataSource = self;
}
// This document loses its responsisibility on the preview panel.
// Until the next call to -beginPreviewPanelControl: it must not change
// the panel's delegate, data source or refresh it.
-(void)endPreviewPanelControl:(QLPreviewPanel *)panel
{
[previewPanel release];
previewPanel = nil;
if (DEBUG) NSLog(#"QuickLook panel control did END");
}
// Quick Look panel data source
-(NSInteger)numberOfPreviewItemsInPreviewPanel:(QLPreviewPanel *)panel
{
if (DEBUG) NSLog(#"QuickLook preview count called");
return [[myArrayController selectedObjects] count];
}
-(id <QLPreviewItem>)previewPanel:(QLPreviewPanel *)panel
previewItemAtIndex:(NSInteger)index
{
if (DEBUG) NSLog(#"QuickLook preview selection of item called");
return [[displayAC selectedObjects] objectAtIndex:index];
}
-(BOOL)previewPanel:(QLPreviewPanel *)panel handleEvent:(NSEvent *)event {
if (DEBUG) NSLog(#"QuickLook panel error handler called");
// redirect all key down events to the table view
if ([event type] == NSKeyDown) {
[myTable keyDown:event];
return YES;
}
return NO;
}
The issue seems to be that the acceptsPreviewPanelControl never gets called, so the delegates never get used (they definitely never get called).
I'm sure this is a simple step that I'm missing, but after dissecting the sample code and scouring over the docs I don't see the answer.
Is it because this is all from within an NSViewController (although I see no reason why that should even come into the equation)?
Any and all help much appreciated.
SOLUTION UPDATE
Thanks to Peter's observation, the fix was a quick one. Don't you hate it when the error message in the debugger means what it says? :-)
In my class that loaded MyViewController I simply needed to add three lines of code to fix the problem.
// mainWindow is an IBOutlet to my window because the calling class
// is a simple object and not an NSWindowController otherwise I could
// have used `self` instead of `mainWindow`
NSResponder * aNextResponder = [mainWindow nextResponder];
[mainWindow setNextResponder:myViewControllerInstance];
[myViewControllerInstance setNextResponder:aNextResponder];
Job done :-) Thanks Peter.
Why would you expect it to send you delegate messages if you aren't (yet) its delegate? If you want it to send you delegate messages, then you need to set yourself as its delegate.
I tried calling a setDelegate, but get warned about impending doom if I continue down that route...
[QL] QLError(): -[QLPreviewPanel setDelegate:] called while the panel has no controller - Fix this or this will raise soon. See comments in QLPreviewPanel.h for -acceptsPreviewPanelControl:/-beginPreviewPanelControl:/-endPreviewPanelControl:.
“No controller”, it says. So, you need it to have a controller.
The comments on that header, particularly on acceptsPreviewPanelControl: and the QLPreviewPanel instance method updateController, suggest that the panel's controller, when it has one, is an object that is in the responder chain. Therefore, if your controller is not becoming the panel's controller, it's because your controller isn't in the responder chain.
So, fix that, and then it'll work.
I would imagine that your view controller should be in the responder chain whenever its view or any subview thereof is in the responder chain, but maybe this isn't the case. The documentation doesn't say. If all else fails, set yourself as some view's next responder explicitly (and its previous next responder as your next responder), then send the preview panel an updateController message.
After so many years, in the swift world, I found this line of code works as well.
Without rearrange the default response chain, just "push" your view controller to be the first responder in the window. I'm not sure if it works for every scenario:
view.window?.makeFirstResponder(self)
And the object setups are the same:
override func acceptsPreviewPanelControl(_ panel: QLPreviewPanel!) -> Bool {
return true
}
override func beginPreviewPanelControl(_ panel: QLPreviewPanel!) {
panel.dataSource = self
panel.delegate = self
panel.currentPreviewItemIndex = //your initial index
}
override func endPreviewPanelControl(_ panel: QLPreviewPanel!) {
panel.dataSource = nil
panel.delegate = nil
}