Avoiding NSTableView NSOutlineView menu row highlight

is there a way to avoid (or customize) the special row highlighting NSTableView and NSOutlineView does when the context menu is shown?

In my case that is confusing and unwanted since I'm ensuring the (right-) clicked row is selected when the menu is displayed and I'd just like to show the "normal" row highlight background -- which I customize by overriding -highlightSelectionInClipRect: in my own NSOutlineView subclass.

> Hello,
>
> is there a way to avoid (or customize) the special row highlighting NSTableView and NSOutlineView does when the context menu is shown?

You can't customize it. Please log bugs requesting that ability.

NSTableView marks the rows to highlight in:

- (NSMenu *)menuForEvent:(NSEvent *)theEvent

If you override that, and don't call super, the it will suppress the highlighting.

>
> In my case that is confusing and unwanted since I'm ensuring the (right-) clicked row is selected

FWIW, that's non-standard UI. The HI specification is to not change the selected row on a right click. Note that many apps get this wrong. Finder in SnowLeopard has it correct.

corbin

> when the menu is displayed and I'd just like to show the "normal" row highlight background -- which I customize by overriding -highlightSelectionInClipRect: in my own NSOutlineView subclass.
>
>
> Thanks!
> Markus
> --
> __________________________________________
> Markus Spoettl

OK that's certainly an option but what does NSTableView do in -menuForEvent:? Just open the popup? Or something more elaborate.

>> In my case that is confusing and unwanted since I'm ensuring the (right-) clicked row is selected>
> FWIW, that's non-standard UI. The HI specification is to not change the selected row on a right click. Note that many apps get this wrong. Finder in SnowLeopard has it correct.

In my case the behavior is absolutely unwanted and confusing to the user. It wouldn't be if I had control over the context-highlight and could manually force rows to go into this state but as it is, it's undesirable for my particular usage.

> In my case the behavior is absolutely unwanted and confusing to the user. It wouldn't be if I had control over the context-highlight and could manually force rows to go into this state but as it is, it's undesirable for my particular usage.

I'd be interested to hear your rationale for your specific situation.

There's been some discussion here about user expectations for
right-clicking. Our current apps change the selection, but I'm pretty
sure most of us want to move to the standard approach of not modifying
the user selection on a right-click.

> <msapplelists...> wrote:>> In my case the behavior is absolutely unwanted and confusing to the user. It wouldn't be if I had control over the context-highlight and could manually force rows to go into this state but as it is, it's undesirable for my particular usage.>
> I'd be interested to hear your rationale for your specific situation.

I have multiple trees lined up side-by-side, each tree shows the same hierarchy in a different version (so the items in the tree are different, not the hierarchy itself) - think of a side-by-side folder comparison with any number of trees. The trees are all sync'd, when you select an item in one tree, the item gets selected in all of them. It creates the perfect illusion of one big view with features that I could never achieve in one tree.

The only thing that doesn't work is the menu highlight because there's no control over it - which I personally find rather surprising given to customizability of the thing in all other areas.

Would there be other solutions? Well yes sure, putting everything in one NSOutlineView, but I would loose a lot of UI goodies that way and thus its not really an option.

> I have multiple trees lined up side-by-side, each tree shows the same hierarchy in a different version (so the items in the tree are different, not the hierarchy itself) - think of a side-by-side folder comparison with any number of trees. The trees are all sync'd, when you select an item in one tree, the item gets selected in all of them. It creates the perfect illusion of one big view with features that I could never achieve in one tree.
>
> The only thing that doesn't work is the menu highlight because there's no control over it - which I personally find rather surprising given to customizability of the thing in all other areas.

So you've got multiple views laid up side-by-side to give the illusion
of one big view?

Instead of changing the selection, could you implement Corbin's
suggestion of overriding -menuForEvent: to not call super, but instead
tell all the sibling views to draw pieces of the "this row was
right-clicked" style? Then you keep the system standard behavior and
maintain your illusion of one big view.

> On Feb 18, 2011, at 12:00 PM, Corbin Dunn wrote:>> You can't customize it. Please log bugs requesting that ability.
>>
>> NSTableView marks the rows to highlight in:
>>
>> - (NSMenu *)menuForEvent:(NSEvent *)theEvent
>>
>> If you override that, and don't call super, the it will suppress the highlighting.>
> OK that's certainly an option but what does NSTableView do in -menuForEvent:? Just open the popup? Or something more elaborate.

It's more elaborate, but overriding it and providing your own menu is perfectly acceptable. FWIW, the table doesn't show the returned menu -- something else does. The table just watches it.

> >>> In my case that is confusing and unwanted since I'm ensuring the (right-) clicked row is selected>>
>> FWIW, that's non-standard UI. The HI specification is to not change the selected row on a right click. Note that many apps get this wrong. Finder in SnowLeopard has it correct.>
>
> In my case the behavior is absolutely unwanted and confusing to the user. It wouldn't be if I had control over the context-highlight and could manually force rows to go into this state but as it is, it's undesirable for my particular usage.

Consider the Mail UI. It is considered bad behavior if right clicking on a non-selected row in the sidebar changed the selection, as it is "heavy weight" and has side effects. The user may want to do something, such as delete that folder, or mark all as read, without changing the selection to it. I'm just saying that changing the selection goes against the standard behavior. It's okay if you do it....just as long as you know the consequences.