I've got this problem on multiple projects with Xcode4/OS X 10.6:
No matter what I do, the editable NSTextField (containing text "Label") will never stick to the right-edge of the parent NSView.
The immediately adjacent NSTextfield (non-editable, text "Sprint Goal") always resizes correctly - with the exact same springs/struts it glues to the right-edge of the parent NSView.
I've got the same generic problem in multiple projects - right-hand-edges of editable NSTextField instances, with floating left-edge, are never, ever honoured. No matter what I do.
Bug? Something fundamental I'm missing here? All my other widgets and controls work "as expected", even with complex layouts. I can't get NSTextField to work even with simple layotus!
Found it!
Possible bug in XCode4, plus human error.
When you single-click an NSTextField, it will sometimes consistently select the item BENEATH that textfield.
In each case in my current project, I had "something" behind the front field - usually a non-editable version of the same field that I was switching back/and forth to based on editable status.
(so I was selecting the NSTextField - but Xcode4 was selecting the item behind it - and then I was making changes to a different item altogether. So, the textfield was retaining its default settings - which are to stick to left, not right)
Related
(using Xcode 8b0 on 10.11.5, but the problem also occurs under 7.3)
My app uses an NSColorWell and two NSImageWells to allow users to set a background (colour, image, pattern). The colourWell behaves just fine. The two image wells do not: if you click on one, it will be selected and it is impossible to deselect both (which is what I want if I am using the colourWell.)
NSImageView does not have a deactivate or deselect method. isHighlighted is false even when the imageWell is clearly marked as selected; setting the highlight on either the imageWell or its cell has no visual effect.
The memory of selection persists even between restarts of the app which makes me think it must be stored in the storyboard somehow, only I cannot work out which property is responsible (I've read through the documentation for NSImageView and NSControl without luck).
By employing a ridiculous dance of disabling and enabling my image wells in specific order (you need to enable the one you want to show up as selected first) combined with subclassing NSImageView to override 'mouseDown' so it sends a notification that I capture to trigger the imageWell's action I have got the behaviour I want, but I would really appreciate an easier way of doing this since 'enable/disable controls in specific order' feels like a hack. (So, alas, feels adding the appropriate drag-and-drop support to a NSButton; I really like the 'drop image, have background change' functionality).
Who or what is causing my NSImageViews to be highlighted and how can I take control of this behaviour?
The answer is that this is not a highlight, which is why setting isHighlighted to false does nothing at all. NSImageView has a property named allowsCutCopyPaste- and if this is set to 'true', the imageWell - or the currently active imageWell if you have more than one - will show this 'highlight'.
After much reading and experimenting, I still cannot get a simple TextView to resize fully in the horizontal direction using Xcode 5.0.2 in Mavericks. It resizes partially as the window is resized, then stops with long lines wrapped around even though my containing NSScrollView continues to resize as expected (it has four default constraints and no horizontal scroller).
Can anyone point me to a simple code/IB+AutoLayout example, preferably just a window containing just an NSTextView dragged in from the IB template library --- one that works? The Apple TextEdit sample code is almost irrelevant for this purpose although it does resize horizontally quite well. Also, there is the clip view for which I can find little information.
Any other tips appreciated.
Thanks.
Answering my own question:
Turns out that my problem had nothing to do with AutoLayout and little to do with NSTextView. It was the textfile I was using to test my code! This file was composed of records with tab-delimited fields.
Turns out that NSTextView comes with a default NSParagraphStyle with predefined tab stops that end at character 56 whereas my test file had tabs beyond that. Therefore, my lines wrapped around at the last defined tab no matter how much I stretched the window.
After changing my search terms, I found what I needed at the following links:
Premature line wrapping in NSTextView when tabs are used
How to have unlimited tab stops in a NSTextView with disabled text wrap
Apologies for wasting bandwidth.
Not sure why such a simple thing does not work in your case, but nevertheless here's what I did in Xcode to get an NSTextView follow window resize:
Create a new project (not document based in my case but it doesn't really make a difference)
Drag a NSTextView from the palette to your window. Align all four edges with the window edges.
Open the "Add constraints" pop-up (second button from the segmented control on the bottom-right part of your IB view.
Each of the four spacing constraints should show a number equal to the distance of your text view from the container window. If you aligned them, this number should be either 0 or -1. Click the down arrow for each of them and select "Use Current Canvas Value". Do it for all four. Make sure no other constraints are selected.
Click on "Add constraints" on the bottom of the panel.
Run your project. Your textview should resize with the window.
Also, as Jay's comment mentions, make sure you do not have any "leftover" constraints in your view. You can check this either by observing Xcode's warnings, or manually by inspecting your view's constraints by going to the Size Inspector tab (4th tab on the Utilities bar).
If you need to have your textview arranged in a more complex layout, it might be worth taking a look at the AutoLayout Guide.
I have an NSTabView which has 5 tabs. Each tab contains an NSTableView (which, as default, is nested in NSScrollView). This is all loaded from a xib file with autolayout turned on. I'd like each table to fully occupy it's respective tab. Using autolayout I select each tab and carefully setup the NSScrollView so that it snaps its top, bottom, lead, and trailing edges to superview. After I do this for the 5 tabs, I'll resize the xib to give it a test. When I cycle back through the tabs, some stay snapped to the superview and some do not. There appears to be some sort of order to this but it is beyond what I can explain.
What's really frustrating is that sometime this will run okay, and sometimes it will crash because of unsatifyable constraints. For now I am using springs/struts but I like autolayout and would like to get it working.
I am afraid that it is the nesting of the tables inside scroll views which is causing the issues.
If you lay this out your own nib, you should be able to reproduce it.
I am hopeful that this can be solved by adding NSLayoutConstraints at runtime, if OSX is anything like iOS's autolayout. Using IB you cannot assing constraints to anythign other than super and sibling (no cousins). This can be done at runtime.
I am hoping someone out there has encountered this issue and has a solution.
Why do the constraints in the layout show a fixed constant instead of auto? Could that be it?
You mentioned cousin constraints, I believe you can add in the in IB if you select two views in the document outline on the left hand side and then add a constraint. I'm unable to pick any two views in IB if I'm using the main window but I can do it in the document outline.
Lastly, you mention it will run okay sometimes but not others - and if that's the case it sounds like something else is adding constraints. Instruments should have a template for tracing constraints, if you can reproduce it you may get a clue to what is introducing the incompatible constraint.
I'm writing an OS X app and have a problem with font smoothing in separate window.
I have a text field where you put text and suggestion window which pops up with a list of suggestions according to what you wrote. I'm using View-cell based NSTableView to display those suggestions and SFBPopoverWindowController to display it as a "popup" window (tried other classes with the same effect). When rows are first drawn they look fine but after I select them (keyboard or mouse) the font changes it's weight. It's only visual - like you would change smoothing method on the font, not it's bold setting.
"Music note" is the selected cell here
What's even more strange is that after I hide and show the window 3 times everything works fine from that point on.
Again - "Music note" is the selected cell.
The selection is done by overwriting NSTableRowView class and its drawSelectionInRect: method but I tried with drawing everything inside custom NSTableCellView class and it didn't help. The text is standard NSTextField - nothing's changed there.
The SFBPopoverWindow (and it's controller) are created once and reused with styleMask NSBorderlessWindowMask, backing NSBackingStoreBuffered, defer set to YES. The only change in SFBPopoverWindowController I made was to turn off window becoming key window but it doesn't change anything.
It might be related to the way a table view draws it's selected cells (setSelectionHightLightStyle:). Try to set the style to None/ NSTableViewSelectionHighlightStyleNone in your code or IB / Storyboard-file and draw the selection yourself (in a NSTableRowView subclass).
Background: When you use NSTableViewSelectionHighlightStyleRegular or NSTableViewSelectionHighlightStyleSourceList the table view assumes that you use the standard selection behaviour and appearance and does some magic to support that.
==========
UPDATE
==========
My previous answer is still valid but since it only describes the problem and hints at a workaround, I wanted to add a real solution. If you want to use NSTableViewSelectionHighlightStyleRegular for your table view (with custom font and colors), you need a way to 'disable' the system magic that comes into place once your row is highlighted. One proposed solution is to decline the first responder status. It has a lot of drawbacks and isn't a good solution at all.
So, let's have a closer look at the system 'magic' that kicks in as soon as the row will be highlighted: NSTableRowView has a property interiorBackgroundStyle that is – according to the documentation – 'an indication of how the subviews should draw'. Furthermore 'This value is dynamically computed based on the set of properties set for the NSTableRowView. Subclassers can override this value when they draw differently based on the currently displayed properties. This method can also be called to determine what color a subview should use, or alternatively, NSControls can have the -backgroundStyle set on their cell to this value.'
I assume that this style will be handed down the subview hierarchy and causes your text fields to look odd. The system assumes that a highlighted cell has a dark background and changes the interiorBackgroundStyle to dark. Other controls try to adapt accordingly.
I think there are two solutions to this problem:
1) Override interiorBackgroundStyle in your NSTableRowView subclass and return the style that fits your interface (in my case it's .light because my highlight color is a very bright blue). This worked for me.
2) If changing the whole style is a bit too much because you only want certain elements to not change their style, you may only need to adjust these subclasses. I haven't tried this yet.
I've been making iOS apps for awhile, but I'm trying my hand at MacOS development. I'm adding an NSTextField to my UI and I noticed in Xcode that one of the options in the graphical widgets is "NSTextField with NSNumberFormatter" which implies to me that I'll be able to restrict the input of the field to numbers and configure the formatter in some way.
When I add the NSTextField with NSNumberFormatter to my UI, I can see it has a formatter outlet which appears to be kind of linked to an NSNumberFormatter (although the name is a little grayed out). However, I can't figure out any way to interact with or configure that NSNumberFormatter.
Any help?
To access the NSNumberFormatter, you have to select it in the dock (that list of objects on the left side of the XCode 4 Interface Builder [IB] window).
If the dock isn't in outline view, e.g., it just shows about 4 icons, click the triangle-in-a-square-button at the bottom of the dock. The dock should now show a "Placeholders" section and an "Objects" section; the objects are your UI objects in a hierarchical outline view.
In the IB window, click your NSTextField; that'll highlight the corresponding Text Field Cell in the outline (you may have to twiddle down some disclosure triangles to see it). The Text Field Cell should have a disclosure triangle; twiddle it down to reveal the Number Formatter. Select it, and you should now be able to manipulate it in the Inspector panel.
(There are a lot of things non-obvious like that in XCode. When in doubt, examine your UI object in the Dock's outline view, or prowl the menus with that object selected. It's amazing--and often useful--what you can discover lurking there!
to configure the number formatter, you can ( after you've selected the formatter ) open the Attributes inspector, select the behavior you want and customize the formatter. At least that worked for me in XCode 4.
– moritz