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 131824 - Property "oldInitialize" set for no visible reason
Summary: Property "oldInitialize" set for no visible reason
Status: RESOLVED WONTFIX
Alias: None
Product: db
Classification: Unclassified
Component: SQL Editor (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-02 13:32 UTC by Andrei Badea
Modified: 2009-05-25 20:55 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 Andrei Badea 2008-04-02 13:32:04 UTC
... in the constructor of SQLCloneableEditor in db.core. Please explain the need for this property. I also can't find
any documentation of it, is it actually documented?
Comment 1 Jaroslav Tulach 2008-04-02 14:48:09 UTC
It is documented in openide.text. 

Maybe you do not need this property anymore after recent Vita's fix?
Comment 2 Andrei Badea 2008-04-03 12:28:56 UTC
Without this property, a race condition between the execution of a newly opened SQL editor (by the View Data action) and
the initialization of the editor might be exposed. The execution code might search the AWT hierarchy for the editor
container before the SQL editor UI has been initialized. However, I couldn't reproduce this race condition in the
current code because the editor UI is eagerly initialized by calls to getEditorPane() from various modules, including
db.core itself. So probably not a P2.

Issue 69466 probably needs to be revied to let the SQL editor know that the editor container has been created.

Removed the oldInitialize property in 47dcf2c8a057.
Comment 3 Andrei Badea 2008-08-05 15:20:35 UTC
... but added it back in c60723e7d854 as a workaround for issue 132028. So leaving open, because I still believe the
property doesn't need to be set, but too risky to fix for 6.5.

Comment 4 Jiri Rechtacek 2009-02-10 15:15:34 UTC
Reassigned to new owner.
Comment 5 Jiri Rechtacek 2009-05-12 16:36:43 UTC
Seems as a obsolete problem.