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 15297 - Changing file-type while using EXPLORER -> FIND removes entries off list
Summary: Changing file-type while using EXPLORER -> FIND removes entries off list
Status: RESOLVED INVALID
Alias: None
Product: utilities
Classification: Unclassified
Component: Search (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Marian Petras
URL:
Keywords:
: 16019 21864 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-09-09 15:48 UTC by _ gtzabari
Modified: 2004-08-19 13:37 UTC (History)
2 users (show)

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 _ gtzabari 2001-09-09 15:48:27 UTC
dev build 200109030100
IBM JDK 1.3

Say I search a directory node (in EXPLORER) for a string and it returns a list of 10 files. Some of these files have no file type. If I click on them and turn them into 
TEXT files, they disappear off the list of results. I don't think they should be removed because whether or not they are text-files they *still* contain the string I was 
searching for.
Comment 1 Jan Zajicek 2001-09-12 10:35:52 UTC
utilities stuff
Comment 2 Peter Zavadsky 2001-10-03 13:27:00 UTC
*** Issue 16019 has been marked as a duplicate of this issue. ***
Comment 3 Peter Zavadsky 2001-10-03 13:28:20 UTC
For SearchResult the converting of the object, means the old data
object was removed and Search doesn't have means how to know it's
going to be replced by new one. So currently it's not fixable in nice way.

This issue will be solved in future (see planned features) when there
will be implemented full dynamic search result -> search result should
be then able to watch creation of new objects in its search scope and
if will contain some matching string be added to result, thus also our
case will pass.

Closing as Later.
Comment 4 _ gtzabari 2001-10-03 14:43:32 UTC
Change issue title (FILE -> FIND) to fix typo

Furthermore, can you not fix this issue by placing an EventListener 
on Explorer which will be fired whenever new objects are 
added/removed. When new objects are added, you run the search on them 
automatically. Or is this exactly what you meant when you 
said "dynamic search"?
Comment 5 Peter Zavadsky 2001-10-03 16:08:54 UTC
In general something like that is necessary to be done.

But in fact it requires much more. Listening on Explorer wouldn't
help. You need to listen on folder objects, its sub-folders (etc) if
they children has changed and then retry the search for only for those
changed  objects. If you would perform the entire search it would
probably damage performance much.

I think it requires much more to be done then it seems (one listener
to set shouldn't be enough and clean), therefore it's planned as new
feature.
Comment 6 pfelenda 2003-04-16 19:57:38 UTC
This issue is still present and should be fixed.
Comment 7 pfelenda 2003-04-16 19:59:58 UTC
x
Comment 8 pfelenda 2003-04-16 20:03:09 UTC
*** Issue 21864 has been marked as a duplicate of this issue. ***
Comment 9 _ gtzabari 2003-04-17 15:41:13 UTC
I'd just like to add a note regarding related issue #16019. I am
expecting the FIND dialog to remove result entries they have been
modified and the search string no longer occurs inside them. For
example, if I search for all files with "class Apple" in them, open
the file via the FIND dialog, and replace them all with "class Orange"
and save the file, I still expect the FIND dialog to remove the entry
from the list since it is no longer a valid match.
Comment 10 Marian Petras 2004-03-12 18:50:07 UTC
*** Issue 16019 has been marked as a duplicate of this issue. ***
Comment 11 Marian Petras 2004-08-19 13:37:41 UTC
This bug is no longer valid. Changing type of a file to text has been
removed in NetBeans 4.0 (currently in beta stage). Also the "dynamic
search results" feature was removed from NetBeans in version 3.5 (see
issue #30613). Marking this bug as INVALID.