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.
| Summary: | caret (text cursor) in editor turns invisible | ||
|---|---|---|---|
| Product: | platform | Reporter: | Paul Ronan <pronan> |
| Component: | Window System | Assignee: | Peter Zavadsky <pzavadsky> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | blocker | CC: | arittner, jdi, mmetelka, ttran |
| Priority: | P3 | Keywords: | FOCUS |
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Windows ME/2000 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
|
Description
Paul Ronan
2002-03-15 08:49:33 UTC
JDK 1.3.1 (and 1.3.1_02) NetBeans 3.3.1 NT 4 SP 6 It always occurs when after running a failing JUnit test I double click a hot-link in the stack trace in the output window which goes to the correct line in my source file but the caret disappears. The only way I can get the caret back is to switch to another windows app then back to NetBeans. It occurs at other times too but the above is easily duplicatable. One issue could be that I have no 'Running' workspace (I don't know why) so there is no workspace change between test and edit. Is this related to issue 13389? this is the case of missing FOCUS_GAINED/FOCUS_LOST events. I recall in the past the editor module had a workaround for it. But Mila has asked to remove the workaround because JDK has supposedly fixed the bug which obviously is not true It was only a kind of visual workaround that allowed the caret to stay blinking in the editor but the focus was not really there (the pressed keystrokes did not go into the editor). I have suggested to remove it because the workaround was misleading by giving the feeling that everything works fine although it really didn't. I can confirm this issue under W2K with JUnit. But on any testcase (failed and ok). Workaround: Focus a native windows program with a textfield. Switch back to Netbeans: the caret becomes visible. This issue causes problems on Mac OS X too. Should I file a seperate bug for that? Peter, If the test case is same, it's enough to mention it here as you did. Otherwise please submit separate issue. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Well, there is nothing new to say here. Since we don't have a reproducible case it needs to be revised/investigated from the code perspective. There is an issue 25996 that appears to be related to this one. reassign to Tim, new owner of AWT/Swing Reassigning to window system (spoke with Peter Z. about this last week). I've seen this a lot in the last few versions of NetBeans - but it seems to have actually got worse in 3.5 RC 1. I used to be able to restore the cursor in the editor either by clicking in a different window and then back on the editor or by minimising and restoring the IDE. But there have been a couple of instances recently where I've had to restart the IDE to get the cursor back! I run NetBeans in Windows 2000. By the way, I don't recall seeing the problem at home where I use XP. Robbie Is here anybody who is able to reproduce it? What JDK? I could prepare patch to investigate where focus is. If focus is in editor pane (inside editor TopComponent) then it is issue for editor module (or owner of given TopComponent). Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it. issue doesn't apply to new window system - verified This issue had *1 votes* before move to platform component |