I'm really getting extremely mad with Xcode, trying to get a ScrollView correctly working. I'm having in fact 2 problems, but I'll separate it in two questions.
First of all, check out this screenshot.
Whether I drag the ScrollView to the top of view or just to the bottom border of the navigation bar, the web view (white square) stays about 60px from the nav bar, as you can see in the simulator.
The only way for me to have the web view aligned just below the nav bar is by dragging the Scrollview to the top of the view, at the top of the nav bar, and dragging the web view all the way to the top too.. Which places (in Storyboard) the web view behind the nav bar. Seems a bit odd, isn't it? The web view object has no attributes assigned to it which could have created that strange space.
What am I doing wrong?
Note: I have less than 40 hours of Xcode experience resulting in knowing nothing of Objective-C lines, but the Xcode interface itself. Learning by tutorials and practice
In the view controller add this method...
- (BOOL) automaticallyAdjustsScrollViewInsets
{
return NO;
}
This will fix it for you.
Related
It's easy to enable the "inspector bar" for text views so that a bar appears at the top of the screen with various formatting buttons. (Although I had some confusion until I learned to make sure I was selecting the text view in a scroll view, and not the scroll view itself). I can either programmatically use [textView setUsesInspectorBar:YES] or go to the Attributes Inspector and check the "Inspector Bar" box in the "Uses" section.
My question is, how can I further control the inspector bar? I'm having trouble finding information on it in the XCode documentation or online. I'd like to be able to position it in a different place on the screen. Being able to pick and choose which specific controls are in the bar would be great too.
The answer is, you aren't meant to further control the inspector bar. There's nothing in the documentation because, well, there's nothing. Apple's saying, use it or don't use it.
However, if you dig into it a bit, you will find that the inspector bar is a very interesting control. It's not displayed as part of the text view, but rather (privately) embedded in the "window view" itself. When I say "window view," I mean the superview of the content view.
If you list the subviews of that "window view":
NSLog(#"%#", [self.testTextView.window.contentView superview].subviews);
You end up with:
2012-08-02 15:59:30.145 Example[16702:303] (
"<_NSThemeCloseWidget: 0x100523dc0>", // the close button
"<_NSThemeWidget: 0x100525ce0>", // the minimize button?
"<_NSThemeWidget: 0x100524e90>", // the maximize button?
"<NSView: 0x100512ad0>", // the content view
"<__NSInspectorBarView: 0x100529d50>", // the inspector view
"(<NSToolbarView: 0x10054e650>: FD2E0533-AB18-4E7E-905A-AC816CB80A26)" // the toolbar
)
As you can see, AppKit puts the inspector bar at the same level as other top level window controls. Now this is getting into the land of private APIs, but simply tinkering with the "window view" shouldn't get any apps rejected.
You can try to get a reference to the __NSInspectorBarView from here. It seems like it is always the subview right after the content view, so something like this may work:
NSArray *topLevelViews = [self.testTextView.window.contentView superview].subviews;
NSUInteger indexOfContentView = [topLevelViews indexOfObject:self.testTextView.window.contentView];
if (indexOfContentView + 1 < topLevelViews.count) {
NSView *inspectorBar = [topLevelViews objectAtIndex:indexOfContentView + 1];
NSLog(#"%#", inspectorBar);
}
NSLog(#"%#", topLevelViews);
Since this immediately breaks if Apple changes the ordering of the top level views, it may not be a good idea for an application for production. Another idea is:
NSView *inspectorBarView = nil;
for (NSView *topLevelView in topLevelViews) {
if ([topLevelView isKindOfClass:NSClassFromString(#"__NSInspectorBarView")]) {
inspectorBarView = topLevelView;
}
}
NSLog(#"%#", inspectorBarView);
I don't know if the use of NSClassFromString() will pass App Store review guidelines, however, since once again, it's dependent on private APIs.
That being said, once you get a reference to the inspector bar view, things still don't work too well. You can try repositioning it at the bottom:
if (inspectorBarView) {
NSRect newFrame = inspectorBarView.frame;
newFrame.origin = NSZeroPoint;
[inspectorBarView setAutoresizingMask:NSViewMaxYMargin | NSViewMaxXMargin];
[inspectorBarView setFrame:newFrame];
}
But you end up with a misdrawn toolbar, so more work would be necessary there:
My ideas would be to try to shift the content view's height up to cover up the gray left-over area (which would have to be done every time the window is resized, maybe tinkering with autoresizing masks may make it easier) and custom draw a background for the inspector bar at the bottom.
EDIT
Oh, and you should file a feature request for this too. bugreport.apple.com
This is four years late, but I feel like someone on the internet may benefit from this in the future. I spent way too long trying to figure this out.
The inspector bar class, as the others have pointed out, seems to be a private class (__NSInspectorBarView). Therefore, it's probably not recommended to modify.
Nevertheless! The curious have to know. The inspector bar is inserted, at the time of this post (April 2016) into the window's accessory bar. You can get a list of accessory views as of OS X 10.10 using the array property in NSWindow called titlebarAccessoryViewControllers[].
Here's some Swift 2.0 code to do just that, assuming you haven't inserted any other accessory views into the window beforehand.
if window.titlebarAccessoryViewControllers.count > 0 {
let textViewInspectorBar = self.titlebarAccessoryViewControllers[0].view
let inspectorBarHeight: CGFloat = textViewInspectorBar!.frame.height // 26.0 pt
}
It's worth noting that accessory views are handled differently in full screen mode apps: https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/FullScreenApp/FullScreenApp.html
I personally would not attempt to move an accessory view, as they are special kinds of views designed to stay in the toolbar (if I fully understood what I have read).
NSTitlebarAccessoryViewController Reference:
https://developer.apple.com/library/mac/documentation/AppKit/Reference/NSTitlebarAccessoryViewController_Class/
Another 3 years on, but I suspect some will find this useful. My specific problem was in having a window fully filled by a tabView - ideal for setting various kinds of user defaults. Only one of these tab pages had a couple of text views for which I wanted the inspector bar visible. Tabbing to that page made the inspector bar appear, and pushed the whole lot down, ruining my carefully planned layouts. Tabbing away from the page did not hide it again.
The obvious thing was to get the inspector bar to appear on the relevant tab page only. Having got hold of it ("on the shoulders of giants" - thanks to giant Vervious) it is relatively easy to reposition it in the view hierarchy. You are still left with the problem of space for an empty toolbar pushing the content down. The window's view hierarchy changes radically when the inspector bar first appears, and I gave up on trying to do anything with it.
My solution is to increase the content view's height. (Why height and not origin I can't say.)
func tabView(_ tabView: NSTabView, didSelect tabViewItem: NSTabViewItem?) {
if let inspectorBar = window!.titlebarAccessoryViewControllers.first(where:
{$0.view.className == "__NSInspectorBarView"} )?.view {
// move content view back to where it should be
var sz = window!.contentView!.frame.size
sz.height = window!.frame.size.height - 21
window!.contentView?.setFrameSize(sz)
// put the inspector where we want it
inspectorBar.removeFromSuperview()
let y = textPage.frame.size.height - inspectorBar.frame.size.height - 10
inspectorBar.setFrameOrigin(NSPoint(x: 0, y: y))
textPage.subviews.insert(inspectorBar, at: 0)
}
}
The code belongs in a NSTabViewDelegate which I made my window controller conform to, remembering to set the tabView's delegate to File's Owner in the xib, and is called whenever a new tab is selected. textPage is the view inside the relevant tabViewItem.
There are some arbitrary constants found by trial and error. The function only need run once. Repeated calls are harmless, but you could put in a flag to make an early return from subsequent calls.
You cannot do anything to position this thing.
Clearly, the corruption noted by #Vervious is real, but only if you do not have an NSToolBar.
You see, this inspectorBar is sadly a mostly private and mostly (publicly) undocumented but awesome tool. And it is very much intended for use in a window that has an NSToolBar visible... go figure.
After you have a toolbar added to your view
Still with a toolbar but hidden, and inspector bar is cool
(as in via the view menu or the method it invokes, which is toggleToolBarShown: and is an NSResponder friendly message )
So it is obvious, no you cannot do much with this. It's design is poorly documented. It works as intended as a pseudo accessory view bar under the place an NSToolbar goes (which is also not adjustable)
UIScrollview scroll is not working when i tested application in device (iPhone 5), But scroll is working properly in iPhone 5/5s/6/6 Plus simulator. I am developing application using Xcode 6 and UIStoryboard with AutoLayout.
I set the top, bottom, left and right constraints of UIScrollview with relative to Superview. And i also set the constraints of every UIControl which is in the UIScrollview.
Has any one have solution regarding this issue?
Please see below screenshot for reference.
It's probably easiest to have the scroll view contain a single view, which then contains all of your scrollable content. That single view should be anchored to all 4 sides of the scroll view, and if it's only meant to scroll vertically (which is what your screenshot makes it look like), then set the content view to be the same width as the parent of the scroll view.
To make sure an UIScrollView scroll, you have to check
Size
Your content View is bigger than your Scroll View. If you want it to be scrolled vertically, make sure its higher; horizontally, wider.
Constraints
Make sure your Scroll View is pinned to its super view, Top, Bottom, Leading, Trailing.
Make sure your Content view of Scroll View DOES NOT have CenterY constraint set to Scroll View, cause that'd make content view stuck with Scroll View and it'd never be able to scroll. (That happens to me the last time I was stuck)
Interface Builder settings
Make sure the check in Interface Builder under Scroll View is checked:
Scrolling section, Scrolling Enabled.
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 a 10.6 app that I am building on Lion with Xcode 4.3
There is a horizontal split view in the main view, containing the following:
The top view contains an NSSearchField with an NSTableView below it.
The bottom view contains a WebView.
I have it working, but when I resize the split view the top view behaves oddly.
What I want to happen is for the search field to remain where it is, the tableview to remain where it is, but to expand if the split view is dragged down. If dragged up, I want the webview to overwrite the search field and table view.
You can see what I mean in this clip: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizemostlyokay.mov
This keeps the things in the right place when I drag up, but doesn't expand the table when I drag down. The view is expanded, but not the table.
So, I changed the autosizing constraint on the table view / scroll view to make it expand when the view is resized. This is what happens: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizeproblem.mov
When the split bar is moved upwards the table view is moved upwards inside the top view until it overwrites the search field. It doesn't move back when the bar is moved back down.
I cannot find a way to make this work by changing the autosizing constraints. This is usually pretty easy stuff, so either I'm missing something obvious or...?
Has anyone seen this behaviour before when creating SL apps on Lion with Xcode 4.3?
FYI, if I replicate this in a new 10.7 project using auto-layout everything works fine.
Regards
Darren.
When you allow an NSSplitView to make one of its subviews very small so that the subviews effectively overlap you get layout issues and this is one of the reasons that Apple introduced auto-layout (watch the WWDC video about auto-layout and I think they demo this problem near the beginning).
If I were you I'd set a minimum size for the top pane so that, for example, it stops resizing when it is 100px high. You can then allow it to collapse so that the user can still show just the WebView.
I'm building my iphone app.
I've got a problem. For every view without the Navigation bar and the Tab bar is pulled up of 20px.
So I have to place every elements 20px below the top edge.
In this screenshot http://ge.tt/4FG1fJ9 you see the Interface builder view, with 20px bar space at the top, and the result into the Simulator.
This solution works, but give me some problems, and it's not elegant.
I'm wondering why all this happens.
Have you got any idea?
Thanks
In Interface Builder, open your xib, click on the root UIView and then hit Cmd-1. That will bring you to the UIView Attributes window. There are a few drop downs for "Simulated UI Elements" and you can set the Status Bar to Black (or whatever the option is). This doesn't add the status bar to your view, it just simulates the size of the status bar so that you can layout your views without having to shift everything down by 20 pixels.
This is a common problem that seems to rear it's head in different ways. The cause, though, usually has to do with poor coordination of the status bar.
I was able to reproduce the problem just now in a test app by adding a 'Status bar is initially hidden' line to my Info.plist and setting it to YES. The app looks fine in the main view, but if I push a new view controller and then set the status bar to display, the new view appears shifted down 20px. That is, the top of the view appears 20px below the bottom of the status bar.
I know that's not a terribly specific answer, but take a look at how you're hiding/showing the status bar in your app, and also how you have the simulated status bar in your .xib files set.