I've got a Mac app involving an NSOutlineView. The view controller containing the outline view implements outlineViewSelectionIsChanging: to set selection state in a custom way on the cells in the outline view (it's view-based). But selectionIsChanging is called on mouse up, not mouse down. I've got other view controllers with other outline views in the app that get selectionIsChanging properly on mouse down, but I can't find a difference. Is this a property on NSOutlineView / NSTableView? Or is there another probable cause of this?
Turns out that if drag-and-drop is implemented on the outline view, it only posts selection messages on mouse up.
Related
My application has a NSTableView configured as a SourceList.
Under the NSTableView are two NSButton two add/remove items in the table.
The table and the buttons are embedded in a NSVisualEffectView (.behindWindow mode).
The result is great and I can see the background through the table and the buttons, BUT, when the app is in background (I give the focus to another app), the tableview and the buttons become black, and the view is not redrawn, as shown in the picture below (taken with an iPhone, because a screenshot does not show the bug!):
And here is the IB structure of the views:
The container view (CustomView) is layer-backed.
Any lead to solve this problem? Thanks in advance !
The problem was that I was trying to have a NSOutlineView translucent (Behind-window blending), but under a TabView.
Apple UI guidelines (here) state the following:
Use an opaque background when a window contains more than one sidebar, and when using a sidebar in a panel or preferences window. All other times, use a translucent background.
Because of the TabView, I was clearly against this rule which had technical side effects (which led to this post :-)).
--> making the NSOutlineView opaque (not as a SourceList) solved the problem.
Are any of your views opaque and implement drawRect:?
I've seen issues like this when a view implements drawRect: but doesn't completely fill the passed-in rect (or all of the rects returned from getRectsBeingDrawn:count:).
I have simple chat application with text messages view-based NSTableView as you can see at the picture below.
Each message contains NSTextView instance having height to fit all the text.
All I need is to start NSScrollView (which NSTableView-instance is enclosed by) autoscrolling while the user selecting text dragging mouse far enough. Unfortunately, autoscrolling doesn't appear. In case of dragging somewhere outside of the text views all succeed.
I tried to call autoscroll:-method directly by simply push NSEvent-instance from NSTextView-subclass "mouse dragged"-event (like in example from this article):
- (void)mouseDragged:(NSEvent *)event
{
[self.scrollView autoscroll:event];
}
As I've overrode all the mouse events and implemented all the text selecting, this method often invokes. But the autoscrolling doesn't seem to work.
UPDATE
I figured out that before calling -autoscroll:-method there must be -mouseDown: of the same object. But it breaks my text selecting mechanism. The point even not in being first responder, there must be nothing but the mouseDown:-method.
Normally, a text view is within a scroll view of its own. Even if that's big enough to show all of the text without scrolling, it's still there. A call of -autoscroll: on anything within that scroll view (possibly including that scroll view itself?) will just try to scroll that scroll view, not the scroll view that contains the table view.
Try calling -autoscroll: on a view higher up in the hierarchy. Either self.scrollView.superview, the table cell view, or the table view.
Note, though, that the table view's scroll view will keep scrolling even after the cell view containing the text view is fully on-screen. In fact, it may keep scrolling it so far that it's off the screen in the other direction. Basically, it doesn't know that you're trying to select within the text view so it doesn't know to stop when the selection extends all the way to the edge of the text view.
Another approach might be to try to use a "bare" text view with no enclosing scroll view. I don't think IB will let you do that, so you'd have to do it programmatically. Bare text views don't play well with auto layout, though.
Can anyone please tell me how to fix the following issue.
I am building an iPhone app using Storyboard. I have a Navigation Controller as root view and off that a view controller. On this I have a few buttons that when clicked takes you to a table view controller. All fine and well, but when I link the buttons to their respective table views, the top navigation bar obscures the top cell in the table view controller.
Does anyone know why this is happening and how I can fix it?
Also it seems to have thrown off my layouts from the view controller from which they inherit.
See attached image for a better explanation perhaps.
I believe this is the intended behavior when using the translucent navigation bar. It's semi transparent specifically so that you can see items pass behind it (e.g. a table scrolling). If you don't want this, changing the navigation bar's style to opaque should solve the problem.
Since I wanted to keep the translucence, I just added a UIView between the navigation controller and the prototype cell (width of the view, height 60). That way the first cell in the table starts beneath the navigation bar but I can still see the scrolling underneath.
This is a bug/feature in IB when you use a translucent navigation bar, the content view runs under the navigation bar. For non transparent bars the content view begins after the bar. If your content view is a UIScrollView (UITableView is a descendent of UIScrollView) the content will be automatically scrolled so as to not be hidden under the navigation bar. So the problem only exist in IB when you run the app everything should be ok.
You just need go to the Navigation Controller properties, then Simulated Metrics, and change the Top Bar to be a Transluscent Navigation Bar WITH PROMPT. And that should be it. No need for that extra UIView
I have created a custom (themed) NSWindow, by creating a borderless window and then recreating all elements of the window border/background inside the content view. I've created the window widgets (close box, zoom box, minimize box) on top of my own fake title bar using -standardWindowButton:forStyleMask:.
Trouble is, when a sheet is presented on top of my custom window (e.g. "save changes...", those buttons do not receive the clicks.
Does anybody know how I can tell NSWindow not to intercept the clicks in my minimize box? It works with a standard NSWindow. When a sheet is up, I can still send both of them to the dock, or zoom the window out.
I thought maybe there's special code in the content view that ignores clicks in subviews while a sheet is up. But it seems as if -hitTest: is called on the content view and returns the minimize widget, but the widget's action never gets triggered.
I guess I could just replace the content view and perform the action in the content view's hitTest if it is the minimize widget ... but that seems a bit ugly.
I'm making a Cocoa application which has an NSSavePanel. During the lifetime of the modality of this panel, I allow the user to toggle between two different accessory views (call them View A and View B) for this panel via a checkbox in both of these views. I'm building on Snow Leopard.
View B is larger heightwise than View A. When switching from View B to View A, Cocoa starts with the height of the save panel plus View B's height, draws View A at the bottom of the panel with a blank space at the top of View A and then slowly animates this space away so that View A slides upwards. This looks okay.
When switching from View A to View B, Cocoa draws View B's components at the very top of the save panel so that they overlap the save panel's own components (text fields, buttons, etc.). It then slides View B downwards to underneath the save panel's own components. This looks ugly.
First off, I'm not sure how to reason about the proper way to animate the transition from View A to View B. Secondly, I'm not sure to accomplish it. I suppose I could just have one accessory view and just show and hide components in this when switching from basic to advanced mode, but this seems kind of a kludge.
Any suggestions? Thanks in advance.
The easiest way I've found to do things like this is to use an NSTabView with no visible tabs that does NOT draw the background. A and B are subviews of the tab view. Use the checkbox to toggle between the subviews of the NSTabView -- create an action method that uses -[NSTabView selectTabViewItemAtIndex:]. Then you don't have to worry about the height changing and Cocoa handles the transition.