ALL,
NSSmallControlSize page has following explanation:
This constant is for controls that cannot be resized in one direction,
such as push buttons, radio buttons, checkboxes, sliders, scroll bars,
pop-up buttons, tabs, and progress indicators. You should use a small
system font with a small control.
Is there any way to set the size for other controls? Namely NSComboBox.
Unfortunately the documentation is not talking about that. It's not even mentioning if it is at all possible.
TIA!
As the page describes, the constant is for controls that cannot be resized in one direction. Combo boxes, like the listed controls, cannot be resized vertically. Therefore it makes sense that the constant would apply to combo boxes.
This can be quickly verified by creating a combo box in Interface Builder, clicking on the Size inspector, and setting its size to Small. Since this works, we can conclude that the small size is compatible with combo boxes.
Related
Desired look
I wish to make a toolbar for my app that will contain some simple buttons, each with a single monochromatic icon. Here is an example of some toolbar buttons similar to I'm trying to achieve, from Mail's compose window:
Notice these buttons have a consistent size, inner padding, padding, and shading. This is a pretty consistent style across macOS, present in Mail, Safari, Finder, etc. This leads me to suspect there's a standardized UI component for creating such buttons.
If I use a segmented control, each button looks correct, with each icon being correctly padded:
Now I would like to add individual buttons that match the style.
Attempt 1
My first attempt was to add a "Push Button" (NSButton) to the toolbar:
This resulted in a wide button that's a bit too short, and not lined up with the segmented control:
Attempt 2
My second attempt was to use a segmented control, with only 1 segment.
This resulted in a button that's the right shape, size, etc., but it was off center relative to its label.
Naturally, I can manually adjust the button to match the goal, but I feel like I'm missing something. What's the proper way to create these standard buttons?
This is actually quite easy to do and you were close already.
You can use NSButton for that. Note that it has different styles (defined in NSButton.BezelStyle) to choose from. The default one is the one to use inside windows and modals. But for toolbars, to match the style of segmented controls and search bars, you can choose the style .texturedRounded.
You can also set the style via Interface Builder. Note that you have to select the button itself, not the toolbar item around it.
To get the correct size, you seem to set the icon within the toolbar item, not the button itself.
Here is my result:
I'm trying to create an application that would be as standard as possible in terms of style.
An image is worth a thousand words: I can't figure out how to make my buttons the same size as in Apple's programs such as Safari or Finder.
As you can see, the sizing I've set in interface builder don't seem to match the size the buttons get when I run the app, but maybe that part doesn't speak in pixels but in points or something? Also, textured rounded button has only width editable, but not height.
In this case, these are NSButtons, but I guess I'll have a similar problem with other control types...
I found it out! The problem was with neither of these two parts outlined in the screenshot, but in the "Toolbar" item, higher in the hierarchy.
There is a Size attribute in the Attributes inspector which defaults to Small, but you can set it to Regular instead, and then the buttons get the same sizing as in Finder and all.
I'm faced with a problem where I need to display some characters in a tree-view item (those belonging to the Symbol charset) using Symbol font while others in the default System font (Segoi UI on my Windows 7).
Custom draw allows us to draw different items using different fonts, but I would like to draw the same item string using different fonts as it applies to each character in the string as told above.
So, what I've done with not-so-pleasing results w.r.t. drawing performance upon a horizontal scroll when the number of items is more so far is this:
I disabled horizontal scrolling in my tree-view control using TVS_NOHSCROLL style (since I'm using my own scroll bar control inside the tree-view window to handle all horizontal scrolling)
I sub-classed the treeview control and in the sub-classed winproc, I handle the horizontal scroll notification and mouse notification (where I do my own hittesting and send message like TVM_EXPAND and TVM_SELECT as a result of mosue clicks/double-clicks). Also the scroll bar range is set based on how wide my custom drawn string is (the maximum length amongst all items).
I draw the string for each item upon receiving CDDS_ITEMPOSTPAINT using my own fonts for each character in the item.
The above approach (I left out some details for the sake of brevity) works BUT there are some problems which makes me post this question here and look for an alternare way:
Problems:
The horizontal scroll bar control I create is hosted "inside" the tree-view control at the bottom of the tree-view window. However, when the number of items goes beyond what the tree-view client area can accommodate vertically, the last visible tree-view item gets obscured by the scroll bar control. This can be solved by not making the scroll bar a child of the tree-view and hosting it outside the tree-view window just below it. But I don't want to do this since the scroll bar should typically be a child window of the tree-view.
This is the major one. Since I draw the items myself at each horizontal scroll, the drawing performance upon horizontal scrolling is very slow and also leads to flicker upon scrolling.
Any ideas will be much appreciated as I've been grappling with this for the last one week without success.
I can also post the relevant code here if you want to see the approach I took but I'm sure there shoould be a better approach to this and there must be some other people who would've faced this problem and solved it in the past.
Thanks in advance.
Custom-draw allows you to draw items however you want. You are not limited to a single font per item. When you receive the NM_CUSTOMDRAW notification, draw whatever you want on the provided HDC for the specified item. You can draw pieces of text in one font, pieces of text in a different font, etc. Be sure to return CDRF_SKIPDEFAULT so the TreeView itself will not try to draw anything on the item.
#Anurag S Sharma: I tried to edit this into Remy's answer. It's incomplete as is, but addresses your comment/concerns and answers this particularly vexing/useful question...
The problem is that ff I return CDRF_SKIPDEFAULT, Windows does not even draw the +/- buttons (expanding/collapsing) nor the indent lines in the control which I do want Windows to draw. – Anurag S Sharma
To retain the lines, buttons, and icons you can use ExcludeClipRect to mask only the text region and instead of returning CDRF_SKIPDEFAULT, return 0 as if you didn't draw anything. This itself would not be necessary if the text of the tree item was empty, except that the margins of the text will always be drawn by the default handler (note that Microsoft's controls do not always respect clipping shapes, but in this case they do.)
To replicate the classic TreeView label style in your custom draw procedure you need to do something like the following:
HTREEITEM item = (HTREEITEM)p->dwItemSpec;
TreeView_GetItemRect(p->hdr.hwndFrom,item,&p->rc,1);
RECT cr, rc = p->rc; GetClientRect(p->hdr.hwndFrom,&cr);
DrawTextW(p->hdc,text,-1,&rc,DT_CALCRECT|DT_NOPREFIX|DT_NOCLIP);
rc.right+=4; rc.bottom+=2; IntersectRect(&rc,&cr,&rc);
ExtTextOutW(p->hdc,rc.left+2,rc.top+1,ETO_CLIPPED|ETO_OPAQUE,&rc,text,wcslen(text),0);
I have a window I'm setting up with auto layout. There is a view in the middle of the window that contains three controls, and I would like the window to refuse to resize horizontally smaller than the intrinsic size of those three controls.
The outer buttons both have horizontal space constraints to "stick" them to the outside of their superview, and the checkbox in the middle has a horizontal space constraint sticking it to the left side of the "Sync text" button. There is also a >= constraint between the "Sync outline" button and the checkbox, to make sure they don't overlap, but the checkbox prefers to hang to the right. All these constraints have a priority of 1000. The window itself has no minimum size specified.
When I use the "Simulate Document" command in Xcode, everything works as I'd expect, and the window won't let you size it smaller than in the screenshot above. However, when I run my application, the window does allow resizing smaller than that width, so that the buttons start to shrink and eventually the controls overlap each other. I'm not implementing any of the size related window delegate methods, so I don't see any place in the app's code where it might be influencing the resizing.
Any ideas on what could be causing this difference in behavior?
OK, I finally figured out what the heck was going on here. It turns out the problem was that I was implementing the -splitView:constraintMinCoordinate:ofSubviewAt: delegate method (as well as the maxCoordinate one) to restrict the size of the split subviews in the vertical direction. Yes, restricting the vertical resizing of the split view affected the horizontal layout of the buttons.
It appears that what happens is that, if you implement those delegate methods, NSSplitView reverts back to using autoresizing masks to layout the subviews rather than auto layout constraints. Since the view containing those buttons is no longer participating in auto layout, the buttons smush together when you resize the window small. In the simulator, the split view doesn't have a delegate set, so all the auto layout stuff works fine in that environment. Note that merely having the methods implemented is enough to trigger this, even if they just return the proposed coordinates unchanged.
The solution ended up being quite easy, which was to delete the delegate methods and replace it with a vertical constraint on the subview to restrict its size instead.
Apple commonly places +/- buttons below tables (NSTableView), e.g. in the System Preferences for Network or User & Groups. See image below:
How can I place identical buttons below my tables directly in Interface Builder without manipulating any interface elements in my code or subclassing any element classes?
If the table has a fixed width, the easiest way is to just use a segmented control NSSegmentedControl. First add it to your view or window:
Change its Style to Small Square, the Mode to Select None and increase the number of Segments to 4 (or keep it at 3 if you only need + and -):
The +, - and other buttons are predefined images of the AppKit framework (NSAddTemplate and NSRemoveTemplate) and directly available in Interface Builder. E.g. you could setup the first three segments as follows:
For demonstration purposes I made the - segment disabled. Unlike most other buttons, disabling a segment of a segmented control only dims the image/text, it does not change the button background. Only disabling the whole segmented control changes the background (and of course disables all segments).
Of course, the last segment should always be disabled, otherwise it would be clickable and change its background when being clicked. As it contains no image or text, it still looks the same after it has been disabled.
Switch to the size setup and uncheck the Fixed checkbox for all segments, except for the last one, make sure it is checked for the last one:
Unchecking Fixed makes the segment width dynamic, that means it will always match the minimum width required for the content.
Finally place the control directly below the table and resize it to match the table width. Here's the result:
Almost perfect, don't you think?
Things get more difficulty if the table width is dynamic (e.g. the table resizes together with the window resizing). A segmented control doesn't support autoresizing, that means you would have to programmatically change the width of its last segment each time the table is resized. Of course, that is not too hard to do and requires only little code but there is one alternative solution that requires no single line of code.
Decrease the number of segments by one and replace the last segment with a gradient button (NSButton) without title:
Its background looks exactly the same as a segmented control, yet it does support autoresizing to always match the size of the table. There is just one problem: It is clickable and this time disabling it doesn't work as this would change the background. Instead just change its Type to Momentary Change (which means the app wants to control the UI change itself when the button is clicked):
And after the button has been placed correctly and made resizable, the result looks as good as before but this time the table can be resizable and the buttons on the bottom will always fit perfectly.