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 36410 - Property Sheet: Focus lost after keyboard entry
Summary: Property Sheet: Focus lost after keyboard entry
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: PC Windows 95/98
: P3 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords:
Depends on: 31896
Blocks:
  Show dependency tree
 
Reported: 2003-10-03 09:04 UTC by bht
Modified: 2008-12-22 19:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2003-10-03 09:04:07 UTC
Product Version: NetBeans IDE Dev (Build 200308251153)
Operating System: Windows 98 version 4.10 running
on x86
Java; VM; Vendor: 1.4.1; Java HotSpot(TM) Client
VM 1.4.1-b21; Sun Microsystems Inc.

When I edit a list box with the keyboard and try
to repeat that then it doesn't work.

How to reproduce:
- Switch to SDI mode.
- Select a Java source file in Explorer.
- Press [Ctrl+1]. The Property sheet pops up.
- Use [Arrow down] to move to the Execution ->
Compiler row.
- Press [F2] and change the selection.
- Press [Enter].
- Press [F2] again.

Expected behavior:
One should be able to repeat this multiple times.

Actual behavior:
After pressing [F2] again, the property sheet
stops responding completely to any keyboard
navigation. There is no focus.

Possible workarounds are:
- Use the mouse.
- Switch to another window and back to the
property sheet.
Comment 1 _ tboudreau 2003-10-06 11:43:17 UTC
Reassigning this issue to myself.  Reproduced on WinXP.

Fix is probably to call requestFocusInWindow on stopCellEditing(). Not
sure yet where focus is ending up - possibly on null.  

The core problems are that 1. Swing doesn't define well where focus
should go when a focused component is removed from a container - what
should happen is that the FocusTraversalPolicy of the container should
be used, but that's not what does happen.  The easy answer to this is
"well, don't remove components that have focus, silly!" but that's
exactly the behavior of a JTable (or for that matter a JTree's rename
field).  2. The old NetBeans window system does strange things with
using focus to track the activated TopComponent, and injects
additional focus events into the flow - where, in a standalone app,
focus goes from Component A to Component B, in NetBeans focus goes
from Component A to null to Component B.  That's fixed in the new
window system but I'll still need to do something here.
Comment 2 _ tboudreau 2003-10-15 21:40:48 UTC
Fixed on property panel rewrite branch
Comment 3 _ tboudreau 2003-12-09 09:36:49 UTC
Property panel rewrite branch merged.
Comment 4 Marian Mirilovic 2005-07-13 13:24:05 UTC
closed