I have an NSPopover that contains an NSTabView which encloses all the popover's content view area. In this setup, I could not drag out the popover even though I've implemented detachableWindowForPopover: correctly in the delegate. I know I have implemented the delegate correctly because if the the tab view's size is reduced slightly (to uncover it's parent view), the popover can be dragged out into its own window.
Question is: How to make the popover can be detached by grabbing any blank area in the tab view?
Here's my object composition hierarchy
NSPopover
-> content view controller (NSViewController)
-> the content view controller's view (NSView)
-> NSTabView
-> (some other views and their controllers for each tab)
Related
I'm trying to drag a view to another, I'm using DragImage method to pass data to my destination(another view), everything works fine, but while I'm dragging its container does not scroll.
the hierarchy:
NSWindow
NSScrollView
NSView -> NSScrollView's Document
NSViews -> NSView's subViews -> Drag and Drop between them.
I need to pass event
Any idea how to fix it?
I've created a custom subclass of UIViewController that acts like a UINavigationController or a UITabBarController. Let's call it a ToolbarNavController. It has a toolbar at the bottom with controls for the user to move to a different content view.
I have two content views aside from the ToolbarNavController's view. Both are loaded from a nib and have their own controllers. The app starts out showing one of them. A button in the toolbar allows the user to switch between them.
When I add these views as subviews of the ToolbarNavController's views in viewDidLoad, they are correctly resized to fill the area between the status bar and the toolbar without overlap/underlap.
But when I try to lazy load the second view, adding it as a subview for the first time only when the user presses the toolbar button, iOS does not resize the view to account for the toolbar in its parent view, and it underlaps the toolbar which messes up my Autolayout constraints. Also, when I don't add the subview in viewDidLoad, if I put the device in landscape orientation before switching to the second view, it loads with a portrait orientation frame.
Bottom line: When inserting a subview in viewDidLoad, iOS sizes it correctly and manages autorotation for it. When inserting it later, I need to detect orientation set the frame myself. (And for some reason when I do this, autorotation kicks in again).
What is going on?
In viewDidLoad, the view is not yet layout for the resolution and interface orientation, and view properties are as they were in the interface designer. So, if you had a portrait view, that is how the initial properties of the view are set when going into viewDidLoad. When you add your view there, you add it to the XIB view. Later, iOS performs layout on the view hierarchy and thus resizes your inserted view as needed. But when adding your view at a later point, the view hierarchy has already been layout, so it is expected that the new view you are adding is also layout correctly.
Best practice is to calculate the size you need using the size of the view you are inserting into. For example, half the width of the containing view, or third the bounds, etc. This way it is independent on the orientation the interface is in.
I'm working on a Universal app, using storyboards, and I've added a UISearchBar and a UISearchDisplayController to one of my table views. I've hooked it all up, and can search fine. The problem is when I push a new view controller onto the navigation stack. On the iPhone, this is fine, but on the iPad, it results in the pushed view controller being offset underneath the navigation bar (I had to manually make the navigation bar reappear so that you could get back).
Then, when you navigate back to the original table view where the search was taking place, the search is still active, but the UISearchBar is now hidden behind the navigation bar, meaning there is no way to dismiss it without deleting the query. It also means that it is not longer usable, since you can't get back in to it.
Probably best illustrated using some screenshots.
Here is how it looks when you first open the tableview:
Then doing the search is fine:
Clicking through to the next screen, we can see the issue:
And then back on the original screen, still doing the search but no search box:
Then, if I delete everything from the search box, and get rid of the overlay, I can see the search box when I scroll the table view up, but can never reach it. I can't get a reliable screen grab of that though.
I've looked everywhere for a solution but haven't been able to find one. I've tried calling [self setNeedsDisplay] and [self setNeedsLayout] in the viewDidAppear method, but that seems to have no effect. It seems to rectify itself if I change the orientation of the device, and I was trying to replicate what it would do in that situation by calling those methods.
The structure of the iPad storyboard is: SplitViewController -> Navigation Controller -> UITabBarController -> UITableViewController (contains UISearchBar etc.f) -> UITableViewController
I submitted this issue to Apple DTS, and they responded:
The structure of the iPad storyboard is: SplitViewController -> Navigation Controller -> UITabBarController -> UITableViewController (contains UISearchBar etc.f) -> UITableViewController
The fact is that your project architecture does not follow our guidelines which are:
From the Combined View Controller Interfaces section of the View Controller Catalog for iOS:
When combining view controllers, however, the order of containment is important; only certain arrangements are valid. The order of containment, from child to parent, is as follows:
Content view controllers, and container view controllers that have flexible bounds (such as the page view controller)
Navigation view controller
Tab bar controller
Split view controller
Basically, you should have a structure as follows:
SplitViewController -> UITabBarController ->Navigation Controller-> UITableViewController (contains UISearchBar etc.f) -> UITableViewController>
I'm currently creating an ipad application.
the idea is to have a toolbar at the top and a tabbar at the bottom.
The toolbar has to be visible on all tabs, so it won't disappear.
I was thinking about having a UIViewController as the main view and put the tool bar in there.
Then adding the uitabbarcontroller to that main view controller, but i'm not sure how to do that.
At the moment i have my tabbarcontroller as the main view and added the toolbar to every tab.
Can anyone help?
Thanks
The Tab Bar Controller should be at the root. What you can do is create a method that returns a propertly configured toolbar & add it to each of the view controller's viewDidLoad (either by using a category method, inheriting a common UIViewController subclass, or simply via a C-style factory method.
This way your hierarchy isn't flipped, and the tab bar is at the root like it should be.
In my iPhone application I've set up a default, blank view called Main View into which various child subviews will be loaded for different parts of the application. It's the same approach as if I was using a tool bar to switch between subviews. That case, in the MainView controller I could hook IBActions to buttons in the toolbar, so that when a button was pressed, MainView added different subviews to itself.
In my situation, though, I need to tell MainView to change its subview from within the subviews. So here are two sister subviews, each with their own controller and xib, that would be loaded as subviews of MainView:
- StartView
- FormView
In StartView, after some animations and welcome stuff, a button triggers the camera image picker. Once the image picker returns the image, I need to tell MainView to remove StartView and add FormView.
It may be the result of a long day or my newness to iPhone OS but I'm stuck getting my head around the right way to set up my objects/controllers.
You never have more than one view controller active at a time. (The nav and tabbar controllers don't control views, they control other controllers.) In this case, you will have a single controller that has the MainView as its view property. It will add StartView and formView as subviews of MainView.
However, this is not a good design. It will overload the MainView controller by forcing it to juggle many views. It would be better to use a hidden navigation controller or a tabbar. Hierarchies of controllers can create the illusion from the users point of view for almost any interface layout you can imagine. There is no need to create a logical structure that mimics the visual one.
From your description you may only need a single view/view-controller pair: Set the formView controller to open the camera view before it displays the formView. When the camera is dismissed it reverts to the formView automatically. No fuss, no muss.