Is there a simple way to create a selectable NSRect in Cocoa? In need a rectangle that can be selected and stays selected after a mouse click.
Thanks.
NSRect is just a struct with a position and size. It's not an object that can actually do anything or have any properties other than a width and height. It sounds like what you want is to create an NSView that can be selected. (Here's Apple's Guide on the subject.)
Though not as immediate as you would like, you may be interested in the management of tracking rectangles and tracking areas performed by NSView class.
This mechanism allows you to define specific areas of your custom view. Then, an event is generated whenever the cursor enters or leaves the area, or a mouse button is pressed in this area (-mouseEntered:, -mouseExited:, -mouseDown:, -mouseUp:, -mouseDragged:, ... of NSResponder class). This up to you to define what you want your application do in response to these events (set the rectangle as selected and display it accordingly).
For an example implementation of this, take a look at the Sketch example included with the Apple developer tools (look in /Developer/Examples/AppKit). Sketch allows the user to create new graphics (including rectangles, but also ovals, lines, and text), select them, move them around in the document, etc. In particular, you'll probably want to look at the SKTGraphic class, which represents a single graphic object in the document, and the SKTGraphicView class, which is an NSView subclass that perform the actual layout and drawing, handling mouse events for dragging views around, etc.
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 would like to have a NSMenu with several NSMenuItems in it. Those items shall behave just like "normal" NSMenuItems, with one exception: I would like to be able to draw the contents (i.e. the "foreground") of each item on my own.
That is:
I would like the operating system to draw the blue highlight when I hover with the mouse, draw the checkmark or dash (to signify "selected"/"part of multi-selection"). Moreover, I would like "normal", i.e. menu-built-in mouse/keyboard behaviour.
I would like to draw the "contents" myself: Ideally, I would imagine that I would have to implement/override one single method drawMenuItem:withCGContext:inRectangle:withTextColor, which basically obtains the item, the CGContext to draw into, the NSRect of the item, and the text color that would be used by Mac OS if it drew the item itself.
I know (suspect very stronlgy) that my wish is probably too much, but I would be perfectly fine with something adequate (e.g. I could imagine fetching the NSRect from the NSMenuItem myself, obtaining the color using something like [NSColor selectedMenuItemTextColor], and the context using something like [NSContext currentContext]).
Of course I considered Apple's instruction on this. However, doing this prevents the menu from drawing the blue highlight background and the check mark. Moreover, as far as I could see, I would have to implement e.g. mouseUp myself.
To sum it up: Is there a way to get a (almost) fully functional menu, where I only customize the contents where usually the menu item title goes (possibly even without custom views)?
The answer is: No.
Since you are replacing the entire view of the menu item you are responsible for the drawing and to handle the events.
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've been reading through the Apple documentation about NSButtons and cells and I really can't seem to understand the distinction between the two. Adding to this complexity, it looks like both of them have a large overlap of methods like setTitle: etc. and I'm not sure which ones I should use.
Can anyone explain what the basic differences are?
Thanks,
Teja
You can think of a control as a cell's representative, or "agent".1 The control is an NSView, which means two important things in these circumstances. First, that it represents an area of a window to be drawn in. Second, that it accepts user interaction.2
The control doesn't do very much itself, though. The cell is the thing that does all the work -- notice, for example, that cells can draw themselves into a given frame. This is the responsibility of a view, but the control defers that to the cell, simply providing an area for drawing.
Likewise, when a user clicks on a control, the control receives the event and figures out what it means, but the work of performing an action in response to the event is passed on to the cell.
If you look at the docs for various control/cell pairs (NSButton and NSButtonCell being one such pair), you will see mention of "cover" methods. This means that the control has methods with the same names as its counterpart cell, which simply call through to the cell's. That's the source of the duplication that you mentioned. When you want to use one of these methods, call it on the control -- as the public face of the pair, it will most likely simply ask the cell anyways.
The best Apple-provided description of the interaction is "How Controls and Cells Interact" in the Control and Cell Programming Topics guide.
1In the sense of a actor having an agent who procures gigs.
2This is not strictly true of all views; it's actually a feature of NSResponder from which NSView inherits.
Excerpted from Cocoa Programming for OS X: The Big Nerd Ranch Guide
“A cell handles the implementation details of the control. For the
most part, the cell’s properties and methods are “covered” by
identical properties and methods in the corresponding control. For
instance, when you change the title on a label, the label’s cell is
doing the work, but you interact with the label’s stringValue
property.
Cells have a long history in Cocoa. They were originally
added to address performance issues: many of the basic tasks of a
control were handed off to the cell, which could do them more
efficiently than the control.
Mac computers are much more powerful
than they were in those days, and cells have become an encumbrance.
Apple has stated that it is in the process of deprecating cells, but
you will still see them in your document outline and in older code.”
NSButtonCell is a subclass of NSActionCell used to implement the user interfaces of push buttons, switches, and radio buttons. It can also be used for any other region of a view that's designed to send a message to a target when clicked.
The NSButton subclass of NSControl uses a single NSButtonCell. To create groups of switches or radio buttons, use an NSMatrix holding a set of NSButtonCells.
NSButton Cell has alot more cutomizable options for drawing and behaviour. The differences are better seen in the classes they inherit from (NSButtonCell inherits from the ActionCell class, while the NSButton inherits from the NSControl class.
Take a look at the documentation better:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSButton_Class/Reference/Reference.html
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSButtonCell_Class/Reference/Reference.html
You should choose based on how you want the buttons to be drawn and behave. If its a simple button you want, use NSButton.
Let's say I have a split view, and I want to fill half of it with a table view (a fairly common use case, I would think). Is there any way to tell the table view to size itself to fit the split view or do I really have to size it manually?
I've done this, the way Jon Hess mentions first. Assuming you're using Interface Builder version 3:
Drag and resize your GUI (tableview from what I understand?) component to fit into the enclosing area the way you want it.
Click it to select it.
Press Command-Shift-I to open the inspector window for this GUI component. The inspector window should now actually show that you've selected a "Scroll View".
Click the "ruler" heading to be able to set the sizing. You'll see to the right an animated representation of how your GUI component will behave within its enclosing GUI component, and to the left another represenation of the same, without animation, but with four springs and two struts that you can turn on or off.
Turn all six things on, making them red.
Voilà :-)
It's generally easier to create the subviews first, then use the Layout/Embed Objects In/Split View menu item to create the split view around them.
As far as I know, doing it manually is the only way to go. However, if you turn on "snap to cocoa guidelines", the inner view will snap to the edges of the enclosing view as you drag towards them. This makes it easier than having to manually mouse the edges into place, or manually edit the sizes to match.
You can set all of the springs and struts of the table view to "on" in the size inspector and that will cause the table view to fill the split view. Alternatively, you can use the outline view in the main document window to place the tableview's enclosing scroll view directly into the splitview instead of in an intermediary custom view.