Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 298590 - Restore Defaults does not quite restore Folder Settings
Summary: Restore Defaults does not quite restore Folder Settings
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build (show other bugs)
Version: 6.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 7.0   Edit
Assignee: Andrew Gvozdev CLA
QA Contact: Elena Laskavaia CLA
URL:
Whiteboard:
Keywords:
: 250096 (view as bug list)
Depends on:
Blocks: 299857
  Show dependency tree
 
Reported: 2009-12-28 19:34 EST by Andrew Gvozdev CLA
Modified: 2010-02-15 21:55 EST (History)
1 user (show)

See Also:


Attachments
Test case (4.88 KB, patch)
2010-02-15 21:00 EST, Andrew Gvozdev CLA
angvoz.dev: iplog-
Details | Diff
patch (3.15 KB, patch)
2010-02-15 21:34 EST, Andrew Gvozdev CLA
angvoz.dev: iplog-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gvozdev CLA 2009-12-28 19:34:50 EST
Using "Restore Defaults" in Folder properties does not restore initial state not having custom properties as opposed to File settings. Consider this case:

1. Set custom Build Settings for a folder in Folder properties, such as add new Include Paths. Refresh the folder in Project Explorer for a good measure. Custom settings overlay is shown.
2. In Folder properties, do "Restore Defaults" and OK it. Still, custom settings overlay is shown even after refresh. "Restore Defaults" in File properties clears the overlay.
Comment 1 Andrew Gvozdev CLA 2009-12-31 20:34:46 EST
*

*** This bug has been marked as a duplicate of bug 250096 ***
Comment 2 Andrew Gvozdev CLA 2009-12-31 20:46:19 EST
I mark the other one as dup as this description is slightly more accurate. The overlay is shown properly as the folder indeed (incorrectly) gets custom settings. If you change the settings of parent folder they are not reflected in the Folder properties anymore.
Comment 3 Andrew Gvozdev CLA 2009-12-31 20:48:01 EST
*** Bug 250096 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Gvozdev CLA 2010-01-01 13:22:42 EST
Corrected one related old error in CProjectDescriptionManager on HEAD but that is not enough to fix the problem.
Comment 5 Andrew Gvozdev CLA 2010-01-12 22:26:12 EST
One clarification - the bug is appears for managed project only. Makefile project is adorned as expected in Project Explorer. Additionally, folders not under source folder are not being adorned at all in managed project.
Comment 6 Andrew Gvozdev CLA 2010-02-15 21:00:58 EST
Created attachment 159136 [details]
Test case
Comment 7 Andrew Gvozdev CLA 2010-02-15 21:34:09 EST
Created attachment 159137 [details]
patch

CProjectDescriptionManager is supposed to cancel out resource descriptions which match the parent descriptions exactly. However root folder resource description delivers settings for more (all) tools versus an ordinary folder providing settings  for filtered tools only. I haven't found a good way to extract all the information I would like from MBS to be available in cdt.core (CProjectDescriptionManager.removeNonCustomSettings()) in order to be 100% correct - but I hope this patch is sufficient, and at least an improvement. It passes the test anyway. The change is that in case of root parent folder only language data of the child (from filtered tools) are being compared instead of looking for exact match in removeNonCustomSettings().
Comment 8 Andrew Gvozdev CLA 2010-02-15 21:55:48 EST
The patches committed to HEAD (7.0)