有效地子类化标准的Cocoa控件 [英] Efficiently subclassing standard Cocoa controls

问题描述

尽管有一个人机接口指南文档（HIG），许多高质量的Mac桌面应用程序使用自定义控件。我的问题是什么是最好的方法开始Cocoa开发的子类化控件？它让我惊讶于这个话题有多少（好）的信息。

In spite of there being a Human Interface Guidelines document (HIG), a lot of high quality Mac desktop applications use custom controls. My question is what is the best approach to start subclassing controls for Cocoa development? It surprises me how little (good) information there is on this topic. What path is the best to follow so you don't end up with a nice but half broken control?

推荐答案

这里有一个检查清单：

• 确保您的控制在双分辨率下正常工作。使用Quartz Debug测试这个。你将需要测试绘图的完整性（在所有状态 - 正常，选择，按下，禁用和任何其他）和操作健全（击中测试匹配项目出现在屏幕/其他目标设备上）。


• 对于额外的功劳，请确保您的控件在1.5（或其他类似的非积分）分辨率下正常工作。


• 点击时测试标准控件的工作原理。你可能会这样做。


• 测试标准控制在半按下（鼠标向内，鼠标向外）时的工作方式。


• 测试


• 测试标准控件在内部拖动时的工作原理。


• 使用其他鼠标按钮（右和中）测试四个以上。


• 测试使用滚轮滚动时标准控件的效果。还可以测试shift + scroll和鼠标（例如，大多数罗技鼠标），向左/向右按钮。


• 测试什么是标准控件做什么当双指滚动


• 测试标准控件在捏合时和解除锁定时的效果。


• 测试标准控件的效果


• 使用全键盘访问功能测试标准控件的工作原理。你能进入它吗？你可以用空格键吗？你可以用回车键输入吗？您可以选择退出吗？


• 测试标准控制对辅助功能查询的响应。使用辅助功能检查器。有关响应辅助功能查询和邮件的信息，请参见 Cocoa辅助功能指南


• 测试您的应用程式，包括但不限于VoiceOver中的自订控制项。 Blindfold自己，尝试单独使用VoiceOver的应用。


• 如果适用，请测试打印您的视图。


• 您可以在其他纸张尺寸上测试打印。如果你在美国，测试A4;否则，测试美国信。


• 如果您要实施滚动浏览器（穷人），测试您的滚动器是否正确响应系统偏好设置中外观窗格中的跳转到（下一页|点击的位置）首选项。 正确表示应该执行用户选择的操作。


• 确保它正确实现了所有四个滚动箭头位置设置：在每端的一个（Mac风格），在下/左端（NeXT风格），在上/右端和两端（高级用户风格） 。和往常一样，你需要同时绘制正确和hit-test /反应正确。 （建议 by @radiofreelunch / 由David Dunham ）


• 此外，如果您要实现卷轴，请确保它响应平滑滚动


• 如果您正在实施某种类型的文本输入字段，或任何响应某种特殊热键（例如Enter在输入行中发送消息）的视图，从右到左（希伯来语/阿拉伯语）文本输入和备用输入法。字符查看器是一个好的开始。


• 此外，测试您不会打破ctrl-q。例如，ctrl-q，tab应始终输入制表符字符。同样通常用于选项+（键），例如输入行中的选项返回。


• 测试它是否正确响应不同的键重复首选项。


• 如果您通过除Cocoa的标准菜单快捷方式处理之外的方式实现任何自定义键盘快捷键（⌘+零个或多个其他修饰符+一个或多个字符键），请在Dvorak下测试您的自定义快捷键行为。没有更快的方式来扼杀我们对您的应用的看法，而不是通过退出来回应⌘'。


• 向从未使用过它的用户显示您的应用，也没有看到任何模型。取消资格程序员资格。如果他们不认识你的控制（无论它应该是什么），重新设计它。


• 测试你的控制是否响应（或者没有响应，如果响应将被拒绝）。如果你曾经说过卷轴在这里或你需要点击是危险的）当你的应用程序在后台。 （由@chucker推荐）


• 测试您的控制功能是否响应，但是当您的应用程序在后台并且用户用⌘键向下点击它时，不会使应用程序前进。 （由@chucker推荐）


• 测试调整视图大小。除此之外，这将确保您正确设置自动调整掩码。您还在寻找绘制错误的元素，缺口等（这部分由@Bagelturf建议）。


• 如果你的控件实际上是一个控件，发送它 sizeToFit ，并确保它做正确的事情。 （由@Bagelturf建议）


• 如果使用鼠标坐标，假设它们是整数。确保正确处理小数，零（正和负）和负数。 （此由@Bagelturf建议的的一部分。）


• 您也可以考虑拆分你的控制成一个控制和一个细胞。在后一种情况下，还要对嵌入NSMatrix和NSTableColumn中的单元格执行所有这些测试。


• 如果您的控件有一个菜单，或更多的边缘。


• 如果您的控制器有一个菜单，测试当使用全键盘访问时，用户可以使用向下箭头键输入该菜单。如果它也是一个文本字段（如组合框），测试这只发生在用户按下文本结尾的向下箭头时;否则，正常文本字段行为应该规则：按下不是最后一行的行应该将光标向下移动一行，并且按下最后一行应该移动到行尾。


• 如果您的控件有一个菜单，测试它在点击时保持打开，并且在打开时不会立即关闭。 您可以使用一个函数来正确完成此操作，和


• 如果您的控件有一个菜单，请测试它是否可导航（所有四个箭头键+ Home，End，Page Up，Page Down） ，可用（空格键/返回按压动作）和可取消（esc）。

• Make sure your control works correctly at double resolution. Use Quartz Debug to test this. You'll want to test both drawing sanity (in all states—normal, selected, pressed, disabled, and any others) and operation sanity (that hit testing matches where things appear on the screen/other destination device).
• For extra credit, make sure your control works correctly at 1.5 (or some other, similarly non-integral) resolution.
• Test how the standard control works when clicked. You'll probably do this anyway. Do as the standard control does.
• Test how the standard control works when half-clicked (mouse down inside, mouse up outside).
• Test how the standard control works when dark-side-of-the-clicked (mouse down outside, mouse up inside).
• Test how the standard control works when dragged within.
• Test above four with the other mouse buttons (right and middle).
• Test what the standard control does when you scroll with a scroll wheel. Also test shift + scroll and, on a mouse that has them (e.g., most Logitech mice), scroll left/right buttons.
• Test what the standard control does when you two-finger scroll in each axis and in both axes.
• Test what the standard control does when you pinch and when you unpinch.
• Test what the standard control does when you swipe with three and four fingers in each axis.
• Test how the standard control works with "Full Keyboard Access" turned on. Can you tab into it? Can you press it with the space bar? Can you enter it with the return key? Can you tab out of it?
• Test how the standard control responds to Accessibility queries. Use Accessibility Inspector. See the Accessibility Programming Guidelines for Cocoa for information on responding to accessibility queries and messages in your control.
• Test your app—including, but not limited to, your custom controls—in VoiceOver. Blindfold yourself and try to use the app with VoiceOver alone.
• If applicable, test printing your view. You can print to Preview if you don't want to kill a tree for your development process.
• Test printing in other paper sizes. If you're in the US, test A4; otherwise, test US Letter. Test still other paper sizes (such as Legal and A3) if you're feeling thorough.
• If you're implementing a scroller (poor you), test that your scroller responds correctly to the "Jump to the (next page|spot that's clicked)" preference in the Appearance pane in System Preferences. "Correctly" means it should do what the user selected.
• Make sure it correctly implements all four scroll-arrow-position settings: One at each end (Mac style), both at the lower/left end (NeXT style), both at the upper/right end, and both at each end (power user style). As always, you need to both draw correctly and hit-test/react correctly. (Suggested by @radiofreelunch/by David Dunham)
• Also, if you're implementing a scroller, make sure it responds to the "Smooth scrolling" preference correctly.
• Test that it responds to different scrolling speed preferences correctly.
• If you're implementing a text entry field of some sort, or any view that responds to some sort of special hot key (like Enter to send a message in an inputline), test right-to-left (Hebrew/Arabic) text input and alternate input methods. The Character Viewer is a good start.
• Also, test that you don't break ctrl-q. For example, ctrl-q, tab should always enter a tab character. The same typically goes for option + (key), such as option-return in an inputline.
• Test that it responds to different key-repeat preferences correctly.
• If you implement any custom keyboard shortcuts (⌘ + zero or more other modifiers + one or more character keys) by means other than Cocoa's standard menu shortcut handling, test your custom shortcut behavior under Dvorak. There is no faster way to sour our perceptions of your app than to respond to ⌘' by quitting.
• Show your app to users who've never used it nor seen any mockups before. Disqualify programmers. If they don't recognize your control as a (whatever it's supposed to be), redesign it. If you ever say "the scroller is over here" or "you need to click that", you instantly fail.
• Test that your control responds (or doesn't respond, if responding would be dangerous) when your app is in the background. (Suggested by @chucker.)
• Test that your control responds, but does not bring the app forward, when your app is in the background and the user clicks on it with the ⌘ key down. (Suggested by @chucker.)
• Test resizing your view. Among other things, this will ensure that you set the autoresize mask correctly. You're also looking for drawing bugs—distorted elements, gaps, etc. (Part of this suggested by @Bagelturf.)
• If your control is, in fact, a control, send it sizeToFit and make sure that it does the right thing. (Suggested by @Bagelturf.)
• If you work with mouse coordinates, don't assume that they will be whole numbers. Ensure that you handle fractional numbers, zeroes (positive and negative), and negative numbers correctly. (Part of this suggested by @Bagelturf.)
• You might also consider splitting your control into a control and a cell. In the latter case, also perform all of these tests on your cell embedded in an NSMatrix and in an NSTableColumn.
• If your control has a menu, test what happens when the control is at one or more edges of the screen. The menu should move over to not fall outside screen space.
• If your control has a menu, test that the user can enter it with the down arrow key when using "Full Keyboard Access". If it is also a text field (like a combo box), test that this only happens when the user presses the down arrow at the end of the text; otherwise, normal text field behavior should rule: Pressing down on a line that is not the last line should move the cursor down a line, and pressing down on the last line should move to the end of the line.
• If your control has a menu, test that it stays open when clicked and does not immediately close when held open. There is a function you can use to do this correctly, and it is available in 64-bit.
• If your control has a menu, test that it is navigable (all four arrow keys + Home, End, Page Up, Page Down), usable (spacebar/return press action), and cancellable (esc) with the keyboard.

这篇关于有效地子类化标准的Cocoa控件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！