Look at the simple app screenshot below. There is a text field and a segmented control. There are three bindings in play:
textfield value binding goes to NSUserDefaultsController values.TextValue
textfield alignment binding goes NSUserDefaultsController values.Alignment
segmented control selectedIndex binding goes to NSUserDefaultsController values.Alignment
So the segmented control controls the text field's alignment.
Problem:
When the text field has first responder, if you click on the segmented control to change the alignment, the text field 1.) throws out the value being edited and reverts to the last bound value, 2.) does not update its alignment, 3.) remains first responder.
Expected behavior would be: when you change the segmented control value the text field resigns first responder, commits the value in the UI to user defaults, and updates its alignment. How can this be done?
You’ve hit a bug and should report a RADAR. There have been many bugs with textfields and bindings when you’re editing a textfield, it’s not an area the engineers focused on originally.
You don’t even need to bind the textField’s value to replicate this, you can just bind the alignment of the textField.
Related
I am a rookie Cocoa guy. I need to design and implement a view which will show collection of labels on Mac OS using Xamarin. These labels will have a text and color associated with them. When shown inside the view, label should expand till it covers whole text and it will be shown with background and foreground colors.
I have attached the picture of this user control on Windows, you can see that labels inside the StackPanel are expanding till they cover the whole text. Hope this gives better idea about my ask.
The $64,000 question is "are these labels controls?" In other words, do you expect the user to click on these to do something, or are they just for display?
If your answer is "just for display", the solution is super simple: Use an NSTextField and programmatically add attributed text (NSAttributedString) to it. Attributed text attaches display properties to runs of text within the field; properties like "background color".
If you want these to be buttons that you can click on, then things get a lot more complicated.
Since you apparently want the button layout to "flow", you might look into imbedding buttons (well, button cells) into an NSTextField using attachments. This is normally how non-text content (say, an image) can be inserted, but with some fiddling it can actually be anything a control cell can draw. See How to insert a NSButton into a NSTextView? (inline).
Warning: this is not a "rookie" topic and will involve control cells and custom event handling.
If I were doing this, I'd probably just create NSButton objects for each label (choosing an appropriate style/look like NSRecessedBezelStyle), create a custom subclass of NSView to contain them, and then override the layout method to position all of the buttons the way I want.
To be thorough, I'd also override the intrinsic size methods so the whole thing could participate in auto-layout, based on the number and size of buttons it contained.
I have a bunch of buttons. They appears as an graphical image. If a user clicked on a button I can determine with
sender.titleLabel!.text!
which button the user pressed. But the title of the button appears in the view. I want only to show the image and give the button a invisible title. But I think that is not possible.
Me second solution is to create for each button an outlet. But I think with 30 buttons that is a very bad solution.
Option 1:
For the button text color property set opacity to 0. The text is there, but fully transparent.
Option 2:
You may use the tag value to identify a button so you do not have to rely on the button title. You can set the tag value in interface builder (Xcode) or in code. (The tag is an integer.)
I usually prefer option 2 as it is resilient to text changes over time (think of typos, translations for other languages etc.).
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.
Quick question! When any NSFormCell becomes the first responder, its placeholder text becomes that of the last NSTextField to have focus. Here's an illustration: http://i.imgur.com/3dlzj.jpg
However, the NSTextFields never encounter this! Have you seen this before? This is happening in Xcode 4.3 — what thoughts do you have?
Thank you!
This isn't an answer, but just some further observations.
I did some experimenting with this, and it's not anything you're doing. If you just drag a form and a text field into a window in IB, and put a placeholder string in the text field, then that placeholder appears in the form if you first select the text field and then one of the form cells (with no code at all in the app). It doesn't matter whether you put any placeholder in the form in IB, it still gets the one from the text field. I also put a button in the window with an action that logs the placeholderString of one of the cells -- it always logs null, even though it shows the text field's placeholder. If you put a placeholder in that cell (in IB), then it logs that placeholder, but if you select the text field and then that cell, the text field's placeholder shows up, but the log still shows the original placeholder.
This looks like a bug to me. It might have something to do with the field editor? Isn't there a shared field editor for all text fields in a view?
I have a weird situation.
I have a longlistselector with MVVM databinding. When one item get's selected, I change the colour of the text to the phone accent colour. But the item doesn't change its colour on the screen. ( even not when I scroll in the list )
If I then just switch to another page and come back, the item colour is changed if I scroll to it if it is not visible. If it is visible, it still hasn't changed colour until I scroll it out of view and back into view, then the colour will also change.
Anyone the same experience?
If you're changing a bound value but it's not being reflected in the UI then this will typically indicate that you're not correctly notifying of the change. Make sure you're implementing INotifyPropertyChanegd on the viewmodel and calling RaisePropertyChanged appropriately.