Tooltip for disabled controls
pavel.safrata at oracle.com
Fri Apr 5 13:48:37 PDT 2013
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
> 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.
> 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.
More information about the openjfx-dev