绑定枚举属性最简洁的方法是什么?

发布于 2024-08-10 11:29:13 字数 931 浏览 6 评论 0原文

我有一个菜单,其中包含枚举中每个值的项目。

菜单:

[ ] Sort by Due Date
[ ] Sort by Priority
[√] Sort by Title

枚举:

typedef enum  CW_TASK_SORT_METHOD {
    CWTaskSortMethodDueDate,
    CWTaskSortMethodPriority,
    CWTaskSortMethodTitle
} CWTaskSortMethod;

属性:

@property(readwrite, assign) CWTaskSortMethod taskSortMethod;

连接它的最简洁的方法是什么?我有两个想法,但都令我不满意。

第一个想法:为每个值创建属性(sortMethodIsDueDatesetSortMethodIsDueDate: 等)这些属性将调用 setTaskSortMethod: 并调用 valueDidChange:@ “sortMethodIsDueDate” 等。然后菜单项将绑定到这些属性。这看起来工作量很大。

第二个想法:将每个菜单项连接到 -(IBAction)updateSortMethod:(id)sender,然后它可以迭代菜单项并根据 sender 设置值。这种方法很好,直到 taskSortMethod 被不同的代码部分更改,此时需要添加代码以保持菜单与 taskSortMethod 同步。

我倾向于第一种方法,因为它在 V 和 V 之间有更好的分离。 C.

还有更好的想法吗?

I have a menu which has an item for each value in an enum.

The menu:

[ ] Sort by Due Date
[ ] Sort by Priority
[√] Sort by Title

The enum:

typedef enum  CW_TASK_SORT_METHOD {
    CWTaskSortMethodDueDate,
    CWTaskSortMethodPriority,
    CWTaskSortMethodTitle
} CWTaskSortMethod;

The property:

@property(readwrite, assign) CWTaskSortMethod taskSortMethod;

What's the cleanest way to wire this up? I have two ideas but both strike me as unsatisfactory.

1st idea: Create properties for each value (sortMethodIsDueDate, setSortMethodIsDueDate: etc) These properties would call setTaskSortMethod: and call valueDidChange:@"sortMethodIsDueDate" etc. The menu items would then bind to these properties. This seems like a lot of work.

2nd idea: Connect each menu item to -(IBAction)updateSortMethod:(id)sender which could then iterate the menu items and set the value depending on sender. This approach is fine until taskSortMethod is changed by a different section of code at which point code needs to be added to keep the menu in sync with taskSortMethod.

I'm leaning towards the first approach as it has better separation between the V & C.

Any better ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

农村范ル 2024-08-17 11:29:13

我认为你的第二个想法是正确的,但有一些事情需要考虑:

NSMenu / NSMenuItem 没有像 NSPopUpButton 这样的“所选项目”的概念。我将使用目标/操作机制来更改排序方法和菜单验证(用户界面验证简介)甚至 NSMenu 委托方法 -menu:updateItem:atIndex:shouldCancel: (NSMenuDelegate 协议参考)根据 -taskSortMethod 的结果更新项目的状态。

由于菜单项仅在显示时才需要更新(此机制为您所做的),因此当 -taskSortMethod 在其他地方更改时,您不必担心自己更新菜单项。

例如:

[sortByDueDateMenuItem setState: ([self taskSortMethod] == CWTaskSortMethodDueDate) ];

IMO,这比尝试过度设计绑定驱动的解决方案要干净得多。

I think you're on the right track with your second idea, but there's something to consider:

NSMenu / NSMenuItem don't have a concept of "selected item" like NSPopUpButton for instance. I'd use the target/action mechanism to change the sort method and menu validation (Introduction to User Interface Validation) or even the NSMenu delegate method -menu:updateItem:atIndex:shouldCancel: (NSMenuDelegate Protocol Reference) to update the state of the item based on the result of -taskSortMethod.

Since the menu items only need to be updated when they're shown (which this mechanism does for you), you don't have to worry about updating the menu items yourself when -taskSortMethod changes elsewhere.

Ex:

[sortByDueDateMenuItem setState: ([self taskSortMethod] == CWTaskSortMethodDueDate) ];

IMO, this is a lot cleaner than trying to over-engineer a bindings-powered solution.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文