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 25707 - DataObject.PROP_VALID not fired when FS changed its root directory.
Summary: DataObject.PROP_VALID not fired when FS changed its root directory.
Status: VERIFIED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: David Konecny
URL:
Keywords: ARCH
Depends on:
Blocks: 25400
  Show dependency tree
 
Reported: 2002-07-17 08:25 UTC by Peter Zavadsky
Modified: 2008-12-22 17:58 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2002-07-17 08:25:57 UTC 
When FS changes its root directory
(FileSustem.PROP_SYSTEM_NAME property), all its
FO's get invalid afterwards.
FS fires vetoableChange vefore the actual change
and then propertyChange.

I would expect the DO would "translate" those
events and fire also vetoableChange and then
possible propertyChange of DataObject.PROP_VALID
property.

The vetoableChange is imporant for the cases,
there is necessary to provide saving related to
the DO, the FO are still valid , what is not
possible after the actual change. (see issue #25400)
Comment 1 Marek Grummich 2002-07-22 11:21:48 UTC 
Set target milestone to TBD
Comment 2 Marek Grummich 2002-07-22 11:23:48 UTC 
Set target milestone to TBD
Comment 3 Marian Mirilovic 2003-03-13 13:43:29 UTC 
Changed owner David S. -> David K.
Comment 4 David Konecny 2003-03-20 10:30:04 UTC 
Radek, could you look at this issue please?
Comment 5 rmatous 2003-03-20 15:51:24 UTC 
DataSystems seems to be condemned to doom and should be
replaced.Minority bugs or enhancements of current DataSystems are
profoundly considered. This isssue seems to be more RFE, than defect.
And I think, #25400 was already fixed, which was  original cause for
this request .
Comment 6 Marian Mirilovic 2003-07-25 19:17:58 UTC 
verifying.