This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 37995 - ActionEvent isn't dispatched on first click
Summary: ActionEvent isn't dispatched on first click
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords: UI
Depends on:
Blocks:
 
Reported: 2003-12-10 18:45 UTC by _ pkuzel
Modified: 2008-12-22 19:41 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Simplified TC that demostrates the problem (1.41 KB, text/plain)
2003-12-11 11:25 UTC, _ pkuzel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2003-12-10 18:45:58 UTC
I have editor, explorer, properties and TODOs
topcomponents. 

i/ Focus in editor. I click by mouse to propeties
on property name, properties TC gets focus but the
name row does not. I have to click once again.

ii/ Focus in editor. I click on TODOs toolbar
button. TODOs TC become active but toolbar action
is ignored. I have to click once again.

iii/ Focus in editor. I click to TODOs table.
TODOs TC is activated and proper cell focused.

iiii/ Focus in editor. I click explorer, explorer
Tc is activated and proper node selected.


i/ & ii/ cases are wrong. Given iii/ works as
expected I think that it works only if user
clicked on inner component that has default focus.

Otherwise the mouse click event is consumed and
not propagated to proper target.

Any clue? Is it WS bug or property sheet and TODOs
focus management is screwed somehow?
Comment 1 _ pkuzel 2003-12-10 18:47:21 UTC
JVM 1.4.2-b27, Metal L&F
Comment 2 Peter Zavadsky 2003-12-10 18:58:48 UTC
There is not consumation of that event in WS (WS even uses
AWTEventListener for that which is processed I guess after the
original events processing). WS does its job as required, it activates
that window.. that's right.

Those problems have to be in particular components. Please, fire
issues against them diretly (i.e. editor and TODO's). They  don't work
on mouse clicks as expected. Don't group them in one like this.
I don't see any connection with WS here.

Comment 3 _ pkuzel 2003-12-11 11:25:38 UTC
Created attachment 12525 [details]
Simplified TC that demostrates the problem
Comment 4 _ pkuzel 2003-12-11 11:27:26 UTC
Attached simple TC showing the misbehaviour. Opened using:

        TestMouseEvents top = new TestMouseEvents();
        Mode mode = WindowManager.getDefault().findMode("output");
        if (mode != null) {
            mode.dockInto(top);
        }
        top.open();
        top.requestVisible();
        top.requestActive();
Comment 5 Peter Zavadsky 2003-12-11 13:02:42 UTC
OK, I'll try it, thanks.
Comment 6 Peter Zavadsky 2003-12-11 15:32:46 UTC
I tired it.. and it has the wrong behavriour.

On the other hand I dind't find an exact cause.. I tried to listen on
the AWTEvents.. the Mouse pressed event is passed there, and is not
consumed by winsys (that's definitely not the cause of this issue)...
problem is there wasn't dispatched the ActionEvent... which happened
just on the second click... Why? I don't know yet.
Comment 7 Peter Zavadsky 2003-12-12 15:06:20 UTC
I've got it.

I.e. I found how to by pass it. But can't explain it precisely yet.
Anyway, the activation is done in task scheduled later, it assures the
component gets the focus... but it breaks somehow the
pressing/releasing of the button:

1) when activated output
2) the going to press the button, (just press, don't release)
3) You see when you press it, the button itself is painted as pressed,
but afterwards it gets focus (the activation) and it is unpressed!
(you are still holding the mouse pressed).

But when I do the activation synch, it works fine.

I'll try to look at it more closer, since the postponing of the
activation was there due to another issue.
Comment 8 Peter Zavadsky 2003-12-12 15:28:08 UTC
A bit deeper observation:

the button is disarmed (setArmed(false) on its button).. therefore it
is 'unpressed'.. the disarming happend on focusLost event on that button.

This is strange.. the button shouldn't loose focus, it should just get it!

Continuing..
Comment 9 _ tboudreau 2003-12-14 00:17:37 UTC
I just filed what may be a duplicate - issue 38080
Comment 10 Peter Zavadsky 2003-12-16 14:45:16 UTC
Fixed in [trunk]

core/windows/../view/ui/TabbedListener.java 1.4
Comment 11 _ pkuzel 2003-12-17 16:25:52 UTC
Thank you, it works now.