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 88445 - '*' and '?' do not work as advertised in Go to Type dialog
Summary: '*' and '?' do not work as advertised in Go to Type dialog
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Petr Hrebejk
URL:
Keywords:
Depends on: 89022
Blocks: 88714
  Show dependency tree
 
Reported: 2006-11-01 18:00 UTC by Jesse Glick
Modified: 2007-01-17 10:09 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 Jesse Glick 2006-11-01 18:00:23 UTC
061031. E.g. "asynch" shows several matches but "asynch*" shows none.
Comment 1 Jan Lahoda 2006-11-01 19:53:12 UTC
Maybe case insensitivity does not work together with '?' and '*'?
Comment 2 Tomas Zezula 2006-11-02 09:32:46 UTC
The GTT dialog has no switch case sensitive/case insensitive. Anyway the dialog
should be replaced by something more standard with OK, Cancel option and case
switch.
I also agree with Jesse that the path to file is important, I have several
checkouts of the Jsr199 and I have to open the file to find out which checkout
is it.
Comment 3 Petr Hrebejk 2006-11-06 09:43:26 UTC
Well, case insensitivity does not work with the wild cards. But on the other
hand I don't think that the dialog advertises that it does.  I don't even think
it should.

Ad the switch) I'm not sure, maybe - maybe not. The less options the better I guess.

Tomas: 
- I Agree with OK and Cancel. 
- There already is a bug filed for the path field. Till it is implemented please
use the tool tip (it shows the path). 
Comment 4 Petr Hrebejk 2006-11-06 16:29:51 UTC
Label for the input field changed to be more specific. (advertises the case
sensitivity of wildacrds). Issue put into the HIE umbrella task to get review. 

/cvs/java/source/src/org/netbeans/modules/java/actions/Bundle.properties,v  <--
 Bundle.properties
new revision: 1.5; previous revision: 1.4
done
Comment 5 Jesse Glick 2006-11-06 18:04:42 UTC
This seems bizarre and confusing to me. The dialog permits case-insensitive
class names. And it permits wildcards. But not both. Why?! Changing the label
will not fix the bug, I think.
Comment 6 Tomas Zezula 2006-11-09 14:07:18 UTC
Agree with Jesse, adding case sensitive/insensitive switch should be much better.
Currently the ClassIndex does not support it, I've added new issue: #89022.
Comment 7 Tomas Zezula 2006-11-10 12:20:08 UTC
A've added case sensitive/insensitive check box

Checking in src/org/netbeans/modules/java/actions/Bundle.properties;
/cvs/java/source/src/org/netbeans/modules/java/actions/Bundle.properties,v  <--
 Bundle.properties
new revision: 1.6; previous revision: 1.5
done
Checking in src/org/netbeans/modules/java/actions/GoToPanel.form;
/cvs/java/source/src/org/netbeans/modules/java/actions/GoToPanel.form,v  <-- 
GoToPanel.form
new revision: 1.5; previous revision: 1.4
done
Checking in src/org/netbeans/modules/java/actions/GoToPanel.java;
/cvs/java/source/src/org/netbeans/modules/java/actions/GoToPanel.java,v  <-- 
GoToPanel.java
new revision: 1.7; previous revision: 1.6
done
Checking in src/org/netbeans/modules/java/actions/GoToTypeAction.java;
/cvs/java/source/src/org/netbeans/modules/java/actions/GoToTypeAction.java,v 
<--  GoToTypeAction.java
new revision: 1.8; previous revision: 1.7
done
Comment 8 Jesse Glick 2006-11-10 21:24:18 UTC
FWIW, I did *not* suggest adding any checkbox and I don't see why you would want
one. I just wanted "asynch*" to work the same as "Asynch*". Jano?
Comment 9 jrojcek 2007-01-15 10:59:11 UTC
I would try to avoid the check box if possible. I can see two solutions:

A) always work in case insensitive mode
B) or, if the user inserts an upper case, switch automatically to case sensitive mode

I prefer B) solution and wildcards should have no real impact here.

(Hrebejk, should I file UI review issues as separate items underneath the issue #88714?)