I am building a Cocoa desktop application. I want to know when a NSView's isHidden status has changed. So far using target/action doesn't help, and I can't find anything in NSNotification for this task. I would like to avoid overriding the setHidden method, because then I'll have to override all the NSView derived class that I am using.
UPDATE: I ended up using KVO. The path for "isHidden" is "hidden", probably because the setter is "setHidden".
You could use Key-Value Observing to observe the isHidden property of the NSView(s). When you receive a change notification from one of these views, you can check if it or one of its superviews is hidden with -isHiddenOrHasHiddenAncestor.
A word of warning: getting Key-Value Observing right is slightly tricky. I would highly recommend reading this post by Michael Ash, or using the -[NSObject gtm_addObserver:forKeyPath:selector:userInfo:options] method from the NSObject+KeyValueObserving category from the Google Toolbox for Mac.
More generally, one can override viewWillMoveToWindow: or the other related methods in NSView to tell when a view will actually be showing (i.e. it's window is in the window display list AND the view is not hidden). Thus the dependency on KVO for the 'hidden' key used above is removed, which only works if setIsHidden has been called on that view. In the override, 'window' (or [self window]) will indicate whether the view is being put into a visible view hierarchy (window is non-nil) or being taken out of it (window is nil).
I use it for example to start/stop a timer to update a control from online data periodically - when I only want to update while the control is visible.
Could you override the setter method for the hidden property so that it will trigger some custom notification within your application?
Related
I'm fairly new to Mac development and am slightly confused by the new "storyboard" feature in Xcode 6. What I'm trying to do is segue from one view controller to another in the same window. As of right now, all the different NSViewControllerSegues present the view controller in a new window, be it a modal or just another window. What I'd like to do is just segue within the same window, much in the same way one would on iOS (though an animated transition is not crucial). How would this be achieved?
If you provide a custom segue (subclass of NSStoryboardSegue) you can get the result you are after. There are a few gotchas with this approach though:
the custom segue will use presentViewController:animator so you will need to provide an animator object
because the presented view is not backed by a separate Window object, you may need to provide it with a custom NSView just to catch out mouse events that you don't want to propagate to the underlying NSViewController's view
there's also a Swift-only glitch regarding the custom segue's identifier property you need to watch out for.
As there doesn't seem to be much documentation about this I have made a small demo project with custom segue examples in Swift and Objective-C.
I also have provided some more detail in answer to this question.
(Reviving this as it comes up as first relevant result on Google and I had the same problem but decided against a custom segue)
While custom segues work (at least, the code given in foundry's answer worked under Swift 3; it needs updating for Swift 4), the sheer amount of work involved in writing a custom animator suggests to me that their main use case is custom animations.
The simple solution to changing the content of a window is to create an NSWindowController for your window, and to set its contentViewController to the desired viewController. This is particularly useful if you are following the typical pattern of storyboards and instantiate a new ViewController instance every time you switch.
However.
The NSStoryboard documentation says, quite clearly in macOS, containment (rather than transition) is the more common notion for storyboards which led me to look again at the available tools.
You could use a container view for this task, which adds a NWViewController layer instead of the NSWindowController outlined above. The solution I've gone with is to use an NSTabViewController. In the attributes inspector, set the style to 'unspecified', then select the TabView and set its style to 'tabless'.
To change tabs programatically, you set the selectedTabViewItemIndexof your TabViewController.
This solution reuses the same instance of the ViewControllers for the tab content, so that any data entered in text fields is preserved when the user switches to the other 'tab'.
Simple way with no segues involved to replace the current view controller in the same window:
if let myViewController = self.storyboard?.instantiateController(withIdentifier: "MyViewController") as? MyViewController {
self.view.window?.contentViewController = myViewController
}
I am using MonoMac to build a desktop download manager for Mac in C#.
My XIB has a Table View, whose columns are bound to an NSArrayController. The array controller is connected to my Main Window Controller through an IBOutlet. The array holds a bunch of HttpDownload objects, which derive from NSObject. These HttpDownload objects contain properties such as TotalSize, TotalDownloaded, Bandwidth, etc. I have decorated these properties with an [Export] attribute.
In the controller I add some HttpDownload objects to the NSArrayController using the AddObject method. A background process, started with Task.Factory.StartNew() begins the download asynchronously and updates the bound properties such as TotalDownloaded and Bandwidth as data is received.
I can see these new values being reflected in the Table View, but only once I've "forced" a UI update, for instance by causing the window to lose focus, gain focus, or by clicking on a button within the window.
I have tried setting Continuously Updates Value in IB, but this makes no difference (and reading the docs, I didn't think it should).
Does anyone know to make the UI update the bound values in "real time", instead of only when a window event occurs?
I figured this out shortly after I posted this question.
It seems that we need to manually call WillChangeValue() and DidChangeValue() for at least one of the keys that are being updated, for instance, when I updated the total downloaded:
WillChangeValue("DownloadedBytes");
DownloadedBytes += bytesRead;
DidChangeValue("DownloadedBytes");
In my case, calling these methods for just one of the updated keys seems to be enough to force an update of all the bound values.
For reference, in Objective-C these selectors are called [self willChangeValueForKey:#"keyname"] and [self didChangeValueForKey:#"keyname"].
In my Cocoa app, I have a sheet with a one-column NSTableView that lists a bunch of files in a directory (the app makes back-ups of it's main database, provides this list to users so they can revert to a particular back-up). The content is loaded into and provided to the table view by an NSArrayController, each object is just an NSFileWrapper (I'm considering using NSURL instead, but I digress). The NSArrayController handles sorting, enabling the buttons when a row is selected via bindings, that's all great. I have an NSWindowController subclass object (BackupsSheetController) that hooks all this up and exists in the sheet's nib.
However, when a user edits one of the cells, I want to respond to that change from BackupsSheetController by appropriately re-naming the file represented by that cell, putting it in its new location. Since the table view is bound to the NSArrayController, I don't get sent the NSTableViewDataSource message – tableView:setObjectValue:forTableColumn:row:. If I set my BackupsSheetController as the datasource for the NSTableView object in the nib, I get sent that message sometimes, but not very often, to say nothing of every time.
Most questions and examples I see out there for this scenario handle this all by using a custom model class for items in their table view, and make some controller object an observer for changing properties that they wish to respond to. In other words, each item would be something like a BackupNode object, and BackupsSheetController would observe each for changes to the name property (or whatever I would call it). That seems totally overkill for my scenario, but I also don't want to ditch the bindings I've already got in use and I don't see another way to do this. Is there another way to do this, to make sure I reliably get the setObject:... message? Or should I drop the NSArrayController and make BackupsSheetController the delegate and datasource for the table?
In the "BackupNode" scenario, I don't see why BackupsSheetController would observe each for changes in its name. That's a very roundabout way of doing things. I would think that the hypothetical BackupNode object would simply do the necessary work in its setter for the name property.
Anyway, I recommend using proper model objects. When you try to build a model with only Cocoa-provided objects like NSFileWrapper, NSURL, or NSMutableDictionary, you end up doing more work in the long run than if you just make a proper model object.
On a tangential topic, why is your window controller in the NIB? It should be the thing which loads (and owns) the NIB, which of course requires that it exist prior to the NIB being loaded, which means it can't be instantiated in the NIB.
I'll start by saying that I'm new to cocoa development. I'm also surprised I didn't find a post about this already, but I've filtered through a number of posts now without success.
I have a set of elements that should change state based on the state of a long running algorithm.
Basically, I have a start button, a cancel button, and a next button. The initial state of the app would be start button enabled, cancel and next buttons disabled. The status of the algorithm should swap enabled / disabled on all the buttons as it progresses.
Every option for manipulating button state I have seen involves coding button.enabled into the controller code. I'm coming from an ASP .NET MVC background as I dive into Cocoa and this seems backwards to me. Shouldn't the view logic be separated from the controller logic in the MVC pattern?
To me, it seems I should be able to emit a couple boolean values as IBOutlets like algorithm running and algorithm success, and bind the button state at the view layer. Do I need to toss this idea? Or am I possibly missing something about the Cocoa version of design pattern (like the object I bind the view to should really be a view model, which interacts with a controller class)? Or, lastly, is there an easy way to accomplish what I'm talking about, and I've just missed it.
You don't need to code the enabled state of the button into your controller. What you can do is declare a BOOL property on your controller such as isBusy and then set this property to YES when you start your long operation and to NO when it's finished. You must do this using Key-Value Coding-compliant methods, which essentially means using the setter, so you'd call self.isBusy = YES;, for instance.
The reason you do this is because you can then use Cocoa Bindings to set up a binding on the UI controls. Go into the bindings inspector for one of your buttons, and bind the Enabled binding to your controller object with a key path of isBusy.
Cocoa bindings uses Key-Value Observing (KVO) to monitor the value of observed properties. When a change occurs in the isBusy property, the buttons that are bound to it will notice and change their enabled state in response.
You might be missing the delegate model of Objective-C. In the example you are giving you could have your controller object running the algorithm and updating its status to its delegate, in this case the view.
i.e your ViewController object will call the doSomething method from the ProgramController; and when its over ProgramController will invoque the somethingDidFinish method from its delegate, as defined in your ProgramControllerDelegate protocol)
I'm developing a document based app. Each document has three windows (and hence three window controllers). I'd like to set it up so that two of the three windows are shared between different open documents (swapping views as needed). Is this possible? Can anyone point me in the right direction (documentation or examples)?
Thanks!
In that case, these shared window controllers should not be owned by any document (since each document would then have its own pair of the “shared” windows), but should be independent, probably owned by the app delegate or the document controller. You may also want to make the windows panels, as an Inspector would be.
You'll want to have each controller track which window is main, and update its window accordingly when the main window changes, because the new main window may have a different document.
Pretty much any tutorial on how to make an Inspector window will help you here.
It looks like you need to override -makeWindowControllers in your NSDocument subclass to create the controllers you want, invoking -addWindowController: on the NSDocument subclass to add your shared window controllers.
I haven't yet had to do this, but those are the methods I'd be looking at.
From Apple's NSDocument class reference:
makeWindowControllers
Subclasses may override this method to create the initial window controller(s) for the document.
- (void)makeWindowControllers
Discussion
The base class implementation creates an NSWindowController object with windowNibName and with the document as the file’s owner if windowNibName returns a name. If you override this method to create your own window controllers, be sure to use addWindowController: to add them to the document after creating them.
This method is called by the NSDocumentController open... methods, but you might want to call it directly in some circumstances.
It is possible, but it'll take a non-trivial amount of work from your side. In summary here's what you need to do:
Override setDocument: in the window controller and maintain the associations that it has to each document.
Make sure that each window controller (NSWindowController) disassociates itself from the document before the window is closed. The same goes for each view controllers that may be handling views inside the window.
Subclass the document controller (NSDocumentController) and take care of document closing to make sure that multi-document windows are detached from documents before any of the documents are closed. NSDocumentController is a singleton and thus you need to add an instance in your MainMenu.xib file to replace the default one.
You can read my step-by-step guide how to add support for multi-document window controllers here.