What's the minimum implementation needed to make a custom NSView with an editable text area? I assume NSTextFieldCell can be used for this. I've succeeded in drawing the cell in the view (which is straightforward), but making it editable seems to require a more complicated coordination between the view and the cell. Is there sample code available somewhere?
Update. I should have made clear that my longer-term goal is to have many more editable text areas on the same view. AFAIU it is better to use cells in that case as they are more light-weight than full-blown views. My updated question is: What's the minimum implementation needed to make a custom NSView with an editable text area using an appropriate NSCell?
What's the minimum implementation needed to make a custom NSView with an editable text area?
Make an NSView.
Put an NSTextField in it.
Remember, NSViews (custom or otherwise) can contain other NSViews, and an NSTextField is a kind of NSView.
If you don't want code outside the custom view class to know about the text field, and it probably shouldn't, the custom view can create the text field and add it to itself as a private implementation detail. To do this, simply don't expose the text field in the custom view class's #interface (aside from the instance variable declaration, which is unavoidable).
The custom view should, of course, not draw wherever it put its text field. It could draw there, but the text field would cover it.
I assume NSTextFieldCell can be used for this.
Yes, if you don't mind reimplementing NSTextField. Adding an NSTextField as a subview of your view is much easier.
If you want to make a grid of text fields (with a dynamic number of them, perhaps), use an NSMatrix of NSTextFieldCells. You can, of course, add the NSMatrix as a subview of your custom view.
If you want to edit a text cell just call editWithFrame:inView:editor:delegate:event: on the cell object. This method requires the NSEvent that started the editing, so you can only call this from an event handler. There also is selectWithFrame:inView:editor:delegate:start:length: which sets up the field editor with an selection. You can use this if you need to start the editing from outside of an event handler.
After the user is done editing you need to call endEditing: on your cell.
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 an NSTextView object within a complex custom view. I need that custom view to be the first responder (for multiple reasons, e.g. to have its focus ring drawn properly). But the NSTextView cursor must still blink as if the text view was the first responder.
Here's essentially what I want to see in my application (a screenshot of the search field in Apple Mail):
Note that the text view is the empty area with the cursor located at the beginning of it. The other elements belong to the parent custom view, which has the focus ring around it. The cursor is blinking!
I couldn't implement that behavior using the standard controls. My final solution is to put the search field in another custom view with broad margins and implement a custom focus ring drawing.
Here's how my drafty control looks like:
I am Creating a tableview using custom cell with textfield. When i enter text in tableviewcell textfield and when i scroll the tableview the data is changing . Means re painting cells . How can i stop reloading cell on drag or scroll in IOS 8 swift
Thanks
If your want your cell not re-used, try to make it a subclass of UITableViewCell with a unique identifier, and do not use the identifier with other cells. I haven't test it yet, just hope it will solve your problem.
Ps. If the textfield's text is still overwritten, make a check at the cell's class file (like making an if-else statement checking if the textfield's text is empty).
Detailed workflow:
In cellForRowAtIndexPath(), after you dequeue the cell, normally you will set some property of your custom cell to refresh the data it holds. To implement this, you need to add a didSet observer on the property at the cell's class file. To achieve the goal you want, you can also add the checking code in the didSet observer.
In Your case. You need to customize your keyboard.
Add [Prev][Next] buttons on top of the keyboard and avoid scrolling.
Basically this idea is useful in form based app. May be your doing that kind.
And yes, Stop relaoding of cells is not good to app. If you will implement this. Apple will not approve your app. So avoid this kind of stuffs.
This is how cells work in a UITableView. The standard implementation of the cellForRowAtIndexPath: method dequeues cells and reuses them.
And ideally your app should save the text from the text fields and change the correct text in the cells depending on their indexPath in the same method's implementation.
If you do not want to do that, a dirty workaround would be to create a new cell every time in the cellForRowAtIndexPath: method instead of dequeuing rows.*
*Do not do this unless absolutely necessary. This is very bad coding practice
I have a custom NSTextView implementation that automatically adjusts the font size so that the text fills the entire view.
I overwrote didChangeText to call my font size adjustment method. Works great when the user is editing text, but didChangeText (and the delegate method textDidChange:) are not called when the text view contents are set via bindings.
The font adjustment code needs to run whenever the text is set/changes, not only when it's changed by the user.
How can I detect all changes to the text in an NSTextView, even via bindings?
Note: If there's a better way to have the text fill the entire text view other than increasing the font size, let me know.
It would be better to set the font attributes into the NSAttributedString that is bound to the text view's "attributedString". In the textDidChange: delegate method, you can just recreate the NSAttributedString with the correct font attributes.
The NSTextView method didChangeText is not called when a binding updates the text (as opposed to the text view updating the model).
didChangeText is the source of the binding update. If you override it and don't call super, the binding is broken. didChangeText calls the delegate method textDidChange.
Unfortunately, didChangeText is also called rather late in the NSTextView update process - after the layout and storage delegate calls.
I found that the NSTextStorageDelegate method "didProcessEditing" was the best way to catch changes to the bound string. Although you have to be careful what changes you can make back to the textview at this point - some calls crashed.
I answered my own similar question more fully here:
NSTextView textDidChange not called through binding
I have an NSCollectionView that I want to accept items dragged from elsewhere in my application.
I implement collectionView:validateDrop:proposedIndex:dropOperation: and collectionView:acceptDrop:index:dropOperation: in the collectionview's delegate and register for the appropriate dragged types. Both methods get called fine when I drag the appropriate types, but I don't get a blue focus ring over the collectionview indicating a valid drag.
Have tried both the collection view and its containing scroll view on Default and External settings for the focus ring. Both are just the standard non-derived Cocoa classes. Wondered if there was anything else I should try. Surely it isn't necessary to subclass NSCollectionView for this?
Thanks
Chris
Focus rings are not typically the correct way to provide feedback about drag destinations. Every view does it slightly differently. NSTextView shows the insertion bar. NSTableView shows a blue line in between rows for Before drop operations, and shows a bezel around the row for On drop operations. (See NSTableViewDropOperation)
NSCollectionView shows a "gap" between existing subviews to show where the items will be dropped for Before drop operations, and it will set the selected property on NSCollectionViewItem to YES for On drop operations. (Note: NSCollectionViewItem doesn't do anything by default to visibly represent the selected property. You must implement that yourself.)
Since NSCollectionView's feedback uses existing subviews only, it appears there isn't any feedback at all for empty NSCollectionView's. You would need to subclass to provide this behavior yourself. You could also file a bug to request that NSCollectionView do this itself.