Tooltip for disabled controls

[Pavel Safrata]

Hi Steve,

On 5.4.2013 22:09, steve.x.northover at oracle.com wrote:
> We can't start delivering events to disabled controls or we will break 
> the universe (even for event filters).  Am I missing something?  There 
> is potential for application code to start running that did not run in 
> the past.  Suddenly, disabled controls in some applications that add 
> filters to standard controls might start to do something when they did 
> not in the past.

I have mentioned that explicitly. I said it is backward incompatible. I 
said existing filters will start running and will need to be checked.

I also said there is not many of them. I just grepped our controls and 
there is about 15 event filters that would need to be looked at, 8 of 
them copy-paste.

>
> The reason that disabled tool items on native platforms have hover 
> help is that they are lightweight (ie. on Windows, no HWND). There is 
> a separate API to disable them versus the API that disables a 
> heavyweight.  So native platforms are relying on the implementation.  
> You will notice that hover help dies not come for push buttons for 
> example on Windows.
>
> Whether hover help should be displayed or not is specific to the 
> control.  For example, in tool bars, we want the hover help. However, 
> when a tree is disabled, we don't expect hover help for the tree item.
>
> The safest way to do this is to add new versions of the events that 
> get delivered when the control is disabled.  Tool items can be changed 
> to use the new events.  Tree items can be left alone.

I think that new events would be too expensive. Apart from adding the 
events, we would need separate picking (means 100% picking slowdown), 
duplicating all the logic for entered/exited generating, etc. And there 
might be design issues, from naming (MouseEventForDisabledNode?) to 
defining what events to duplicate or how to handle DnD etc.

Thanks,
Pavel

>
> Thoughts?
>
> Steve
>
> On 05/04/2013 3:01 PM, Richard Bair wrote:
>>>> So are the CSS rules designed such that disable will still be 
>>>> applied, or will the hover rules take precedence? We'd have to try 
>>>> it out.
>>> I've tried. As I expected, controls fully rely on the events not 
>>> being delivered. When I deliver events to a disabled button, the 
>>> button stays grayed, but works normally - gets highlighted on 
>>> hover/armed, gets pressed etc.
>>>
>>> When I deliver the events to filters but not to handlers, everything 
>>> looks fine on the first sight.
>> I like this idea, lets continue pursuing it and see if it works out.
>>
>> Richard
>