On 14.11.16 19:41, Semyon Sadetsky wrote:
247 * If this toggle button is a member of the {@link ButtonGroup}
which has
248 * an another ***focusable*** toggle button selected, and the
focus cause argument
in Swing a component may not receive focus if it is disabled, invisible,
non-displayable...
According to the spec the result will be the same if you call
Component#requestFocus on ***this*** toggle button.
It just confirms that the new spec is not complete, result of
"Component#requestFocus on ***this*** toggle button" will be different
from the result of "selected#requestFocus(FocusEvent.Cause)" if the
selected component is disabled. Because "Component#requestFocus on
***this*** toggle button" will select "this", and
"selected#requestFocus(FocusEvent.Cause)" will select nothing.
I did not get this. There two results of the call 1)
selected.Component#requestFocus 2) this.Component#requestFocus. Of cause
they are different.
Yes they are different and can results the different results, but
currently spec says the opposite: "(1) method execution is the same as
calling (2)". It will be good to rephrase it somehow that we will try to
move focus to the selected component.
They cover 100% of outcome. "select nothing" is not
mentioned in the spec. Is it really needed?
The property "***focusable***" is a defined in the
Component#isFocusable() and have nothing related to visibility, enable
state/etc. It will return true if component is disabled.
I did not mean isFocusable property, but the general capability to get
focus. The standard check for focusability is isVisible() &&
isDisplayable() && isEnabled() && isFocusable().
What you mean is not "focusable" but possibility to be a "focus owner".
If a component is disabled it cannot receive input focus, see
java.awt.Component#isEnabled specs. The proposed spec clearly
states :
247 * If this toggle button is a member of the {@link
ButtonGroup}
which has
248 * an another ***focusable*** toggle button selected,
and the
focus cause argument
It seems that the code in getGroupSelection() will focus the first
element in the group, but what elements will be focused if we call
Component#requestFocus(FocusEvent.Cause) directly for this disabled
compoenent? Will the the same(first) element be selected?
I did find any mentions of "first element" in the proposed spec.
Please
clarify this question.
According to the proposed spec the case when
Component#requestFocus(FocusEvent.Cause) is called on disabled
component
will be handled as:
253 * In all other cases the result of the method is the
same as
calling
254 * {@link Component#requestFocus(FocusEvent.Cause)} on this
toggle button.
The specification states that the call to
this.requestFocus(FocusEvent.Cause cause);
and the call to
selected.requestFocus(FocusEvent.Cause cause);
produce the same result "If this toggle button is a member of the
{@link ButtonGroup} which has an another focusable toggle button
selected, and the focus cause argument denotes window activation or
focus traversal action of any direction"
The question was "is that always true if the selected element is
disabled(but focusable)"? I guess that the implementation in the fix
will select the first "this"(the button on which requestFocus() was
called), but in the second case something different will be selected.
On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote:
On 10/19/2016 8:14 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8074883
webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/
To avoid unexpected selection change the selected button of a
button
group should always grab focus when focus is transferred form
component outside the group to any unselected button inside the
group
in case of traversal or initial container activation actions.
- It is better to pass the cause and boolean focusInWindow
arguments
to the getGroupSelection() method to avoid some code duplication
like
switching over the same cause values.
- The fix will require a CCC request because it updates a
javadoc
for the publci method.
Thanks,
Alexandr.
--Semyon
--
Best regards, Sergey.
