This is a small part of our focus/validation framework.
I just try to explain it as simple as possible.
javax.swing.InputVerifier gives only access to the source component.
We need to know the target component.
Would it be possible to overload verify(..) (or introduce another
method) which
Exactly, the target can reject the focus transfer (and the source too).
All our UI components support "FocusRequestEnterExit" listeners
which has a requestEnter(EnterExitEvent) and requestExit(EnterExitEvent) method
(among others focusGained/focusLost methods).
The EnterExitEvent has a reject()
YW.
You can track the new request here
https://bugs.openjdk.java.net/browse/JDK-8154431
--Semyon
On 4/18/2016 11:26 AM, Reto Merz wrote:
That sounds good.
Thanks for you efforts.
Best Regards
Reto Merz
On 4/14/2016 22:11, Semyon Sadetsky wrote:
On 4/14/2016 9:25 PM, Reto Merz wrote:
That sounds good.
Thanks for you efforts.
Best Regards
Reto Merz
On 4/14/2016 22:11, Semyon Sadetsky wrote:
> On 4/14/2016 9:25 PM, Reto Merz wrote:
>
> This is a small part of our focus/validation framework.
> I just try to explain it as simple as possible.
>
> javax.swing.InputVerifier
On 4/14/2016 9:25 PM, Reto Merz wrote:
This is a small part of our focus/validation framework.
I just try to explain it as simple as possible.
javax.swing.InputVerifier gives only access to the source component.
We need to know the target component.
Would it be possible to overload verify(..)
Thank for explanation.
It seems to me such functionality belongs to the input validation domain
and should not be mixed up with the Swing focus transfer internals.
Swing has javax.swing.InputVerifier which you could extend and set to
each component of your framework. I suppose it would be
Okay... You said the you need to intercept the focus request in the
place where the target is set.
From my point of view opening
Component#requestFocusInWindow(CausedFocusEvent.Cause cause) resolves that.
But it looks like you need extra. What is the final purpose? Maybe you
want to reject
Thanks for your investigation Semyon.
Make Component#requestFocusInWindow(CausedFocusEvent.Cause cause)
public/protected will not help us.
I can explain it more detailed if you want.
What would help is to introduce a "protected boolean
Component#isRequestFocusAccepted()"
which is invoked by
Hello Semyon,
We need to know the target component: "which component will be focused".
Target component means the component which should be "really" focused,
so this can only be known after all the FocusCycle / FocusTraversalPolicy logic
has processed.
DefaultKeyboardFocusManager
Hi Reto,
It is unlikely that AWTAccessor API may be opened. It gives access to
internal undocumented methods not to even mention that those methods
have private and package accesses.
As I understand you need the way to intercept focus transfer initiated
by a traversal key. Why to subclass the
Hello Alexandr,
Basically we need to detect and intercept focus changes.
java.awt.Component allows to override this methods:
requestFocus()
requestFocus(boolean)
requestFocusInWindow()
requestFocusInWindow(boolean)
requestFocus() is only invoked when the component is focused by a mouse click.
Hello Reto,
Could you provide use cases which illustrate tasks the requested API
is intended to solve in your application?
Please, also create a request in the bug system
http://bugreport.java.com/bugreport
Thanks,
Alexandr.
On 11/04/16 12:26, Alexander Scherbatiy wrote:
Resending the request to awt-dev alias.
Thanks,
Alexandr.
On 4/4/2016 4:54 PM, Reto Merz wrote:
Hello,
Jigsaw will disallow access to internal packages.
We have written a complex validation and focus management
implementation
for our closed-source RIA and maintain it since JRE 1.4.
For
13 matches
Mail list logo
