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 13238 - Method refresh on folder should also fire fileChanged. Not only fileCreated and fileDeleted.
Summary: Method refresh on folder should also fire fileChanged. Not only fileCreated a...
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: rmatous
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-06-27 11:12 UTC by rmatous
Modified: 2008-12-22 17:57 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Description of how to reproduce the problem (894 bytes, text/plain)
2003-05-20 09:52 UTC, pedrorg 		Details
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 rmatous 2001-06-27 11:12:38 UTC 
Method refresh on folder should also fire fileChanged. Not only fileCreated and 
fileDeleted.
It is inconvenient to refresh all children of folder if you need to know if 
children were changed.
Comment 1 Jan Chalupa 2001-11-27 13:04:40 UTC 
Target milestone -> 3.3.1.
Comment 2 Marek Grummich 2002-07-22 11:14:17 UTC 
Set target milestone to TBD
Comment 3 Marek Grummich 2002-07-22 11:17:39 UTC 
Set target milestone to TBD
Comment 4 pedrorg 2003-05-20 09:52:25 UTC 
Created attachment 10343 [details]
Description of how to reproduce the problem
Comment 5 pedrorg 2003-05-20 09:53:55 UTC 
Sorry, the attachment is not for this issue.
Comment 6 ehucka 2004-03-04 09:39:20 UTC 
I increased priority.
I think there should be a way to notify external update of files to
Java Code Completion or Java hierarchy etc.
Comment 7 Jan Becicka 2004-03-04 11:38:13 UTC 
Fact, that fileChanged is not fired is a bug, isn't it? We need this
functionality to keep java model up-to-date.
May I request this functionality to be implemented for promo-D?
Thanks
Comment 8 ehucka 2004-03-04 12:30:20 UTC 
If the IDE design contains the fileChanged throwing after Refresh
folder action than it is DEFECT.
Comment 9 rmatous 2004-03-04 13:58:08 UTC 
No, Idon't think so. 

Currently designed:  
If you refresh folder you get information about its content - child
created or deleted. If you want more specific information whether some
child was modified then you must call refresh on that child. So,
everybody can call refresh on folder, then iterate through its
children and call refresh which is actually what you request.


If you don't like current behaviour then ENHANCEMENT is the right
type. But you must be aware that it adds some performance penalty and
I'm not sure if everybody who calls refresh on folder needs your
proposed change. 

Javadoc says:
*Should check for external modifications. For folders it should reread
* the content of disk, for data file it should check for the last 
* time the file has been modified.

This comment is a little vague and it may depend on interpretation but
from my point of view your request would mean incompatible API change
or adding new refresh method.
Comment 10 ehucka 2004-03-04 14:33:12 UTC 
Interesting. And how can I call refresh on a data file?

There are many tools which can make some operations on files externaly
(source generators, refactings etc.). And what a user wants to do is
to refresh all these modified files (maybe hundreds) in IDE after
these operations.

For example, Refactoring module needs to check last timestamps of
files and it should be notify about all changes of source files to
reparse them by a user request.
This is in that Javadoc I think: "...for data file it should check for
the last time the file has been modified".

Java and refactoring are waiting for fileChanged events :).
Comment 11 ehucka 2004-03-04 15:05:58 UTC 
OK. It is not related to action 'Refresh Folder' but to API method. I
created new issue 40762 to descripe this problem.
Comment 12 Jan Becicka 2004-03-04 15:37:29 UTC 
I don't want to argue, if this issue is ENHANCEMENT, BUG of FEATURE
request. But for refactoring team it si a P2 issue. :) 
As Eman mentioned before, tracking external changes is a must for us.

I don't think that I request incompatible change. Javadoc does not
say, that refreshFolder doesn't (or does) fire fileChanged. It depends
on interpretation. What functionality do you think this proposed
change break?
Comment 13 Jesse Glick 2004-04-30 23:09:37 UTC 
See also issue #33162.
Comment 14 rmatous 2004-12-21 11:42:19 UTC 
Already fixed in NB4.0.