Tooltip for disabled controls

[Pavel Safrata]

This would work and would increase backward compatibility of the 
solution. We would still need to fix picking to pick the disabled nodes 
and then let dispatchers decide whether or not to deliver the event to 
the individual handlers. This can have slight behavioral impact on 
certain unusual use-cases (I can elaborate if you want) but I think it 
can be considered as bugfix.

The price is the increased complexity. Any idea of a good name for such 
interface?

Thanks,
Pavel


On 6.4.2013 1:57, Scott Palmer wrote:
> I like this idea too.  If it is acceptable breakage as far as the 
> backward-compatibility goes then I would say it is the cleanest 
> approach.  It is basically what I was trying to do with the idea of an 
> alternate event chain... the alternate chain being just to avoid 
> breaking the existing filters and handlers.  Here is another idea. 
>  How about a new interface that extends the EventHandler.. it is only 
> a marker interface to use with event filters to indicate that you 
> should deliver events for disabled controls?  That way all existing 
> Event Filters still don't get called.  Would something like that work? 
> I haven't taken the time to think it through.
>
>
> Scott
>
> On Fri, Apr 5, 2013 at 3:01 PM, Richard Bair <richard.bair at oracle.com 
> <mailto:richard.bair at oracle.com>> 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
>
>