Suggestion for enhancing the file finder functionality

[Uwe Keim]

As posted here ,I suggest the following enhancements:

The two main advantages of VSFileFinder compared to your tool is:

* The filter window is modeless and dockable as a normal panel.
* The filter text box allows for multiple entries separated by white space to be filtered for, combined internally with "AND".

Maybe you are interested in enhancing your tool in that way, so one would not need VSFileFinder anymore.

Thanks
Uwe

[Sergey]

This is an expanded reply re-posted from MS forum...

Advantages is rather subjective topic. It basically boils down to VS toolwindows vs. modal dialogs design approach. I strongly feel toolwindows is not the right approach most of the time for 2 reasons. 1 - I value my VS real estate and don't want extra clutter. And 2 - toolwindows are always there and thus require some sort of polling most of the time (VS code model just doesn't cover all scenarios), which slows down VS editor. I much prefer deterministic functionality that modal dialogs bring.

In case you're wondering, VSFileFinder polls on a timer set to kick in ever 1/4 of a second.

* The filter window is modeless and dockable as a normal panel.

So, taking the above explanation into consideration, this one is not likely to happen any time soon. There will be a new maintenance release 2.5.6 out this weekend. For the next version 2.6 the plan is to add toolwindow support for Code Browser feature. There are no similar plans for other features though.

* The filter text box allows for multiple entries separated by white space to be filtered for, combined internally with "AND".

This one is not too bad. I'm just wondering... how does VSFileFinder handles spaces when there are file names with spaces in the project? I personally don't think I'd use this feature though.

Did you know that every DPack's browser, File Browser included, supports wildcards (* and ?) in the filter edit box? This allows you to expand the filter coverage tremendously and could be a nice substitute for your request.

Thanks for your feedback.

[dnk.nitro]

I have one more useful (I hope ) suggestion:
It would be great to have small (~0.5 sec) delay between last key press while in file browser and actual search performed among files. This will help for solutions with thousands of files (actually I am working on such solution).

[Sergey]

I have one more useful (I hope ) suggestion:
It would be great to have small (~0.5 sec) delay between last key press while in file browser and actual search performed among files. This will help for solutions with thousands of files (actually I am working on such solution).

How big is your solution? Are you seeing a significant delay while filtering files using File Browser? What kind of CPU/RAM/HDD does your computer have?

On my 2Gh laptop with 1Gb of RAM and 5400RPM HD, search's almost instantaneous on 1200 files solution. Thanks.

[Sergey]

dnk.nitro,

Just implemented your request for the next v2.6. Beta should be available in few weeks. Thanks.

[Sergey]

Uwe,

FYI, newly released beta 2.6.0.1 features dockable File Browser. Thanks.

dnk.nitro,

Your request's been implemented in the same v2.6.0.1. Thanks.

[zythra]

Oh man, I have to admit I can't stand the delay, and neither can my co-workers. Is there a flag somewhere to turn it off?

[Sergey]

zythra, you mean the delay introduced in response to dnk.nitro request? I.e. delay that forces browser update to occur after user had stopped typing for a brief moment.

[zythra]

In the file browser. I hope I didn't post this in the wrong thread, I may have misunderstood what dnk.nitro was requesting.

I am referring to the delay in the file browser (the window brought up by Alt+U).

Sorry if there was any confusion.

[Sergey]

Oh no problem at all. I'm just trying to understand what the issue is.

Have you tried the latest beta version 2.6.0.1? If you accept last installation page defaults then File Browser will be docked. In that toolwindow mode there is only one time when you incur startup load time penalty and that's when you bring it up for the first time. After that it should be very, very fast to come up.

In standard dialog mode it has to scan the solution every single time to get the list of files. That shouldn't but could take a while and largely depends on 1 - size of your solution and 2 - how fast is your computer. Just curious, what kind of solution/pc do you have?

[zythra]

Hehe, I think we *were* on the same page and my wording in my last reply got us off. I'm actually fine with the time it takes to bring the window up, it's the typing delay I don't like.

I'm sorry Sergey, I don't know how you put up with all of us users, especially for a free product! We do appreciate it though.

OT: Have you ever thought of opening up the source and getting help?

[Sergey]

I'm actually fine with the time it takes to bring the window up, it's the typing delay I don't like.

Yeah, I agree. I originally thought that was a good idea but on a regular size solution, even on one with 1 or 2 thousand of files, it makes the search feel sort of sluggish. I think I'm going to disable it for the next beta and introduce a registry configuration option for people that still want that.

Expect to see a new beta posted this weekend.

OT: Have you ever thought of opening up the source and getting help?

I've been asked this before. Visual Studio SDK (aka VSIP) used to be a stopping block for OS. With VS 2005 SDK v3 relaxing a lot of the legal stuff, it's now allowed to provide source code for VSIP packages (that's what technically DPack is).

Unfortunately, that legal lingo hasn't changed for VS.NET 2003 at all. But considering my latest VS poll results, v2.6 will be the last version to support VS.NET 2003. So, moving forward, v2.7 will be VS 2005 only. That theoretically could be the time to consider OS again.

And there is still one issue of VSIP package Id. That's something issued to a particular entity, my USysWare, Inc. in this case. So, even if you get the source code, you'll still need to get a new Id issued to have your custom package loaded by VS.

For testing purposes though, one can disable package Id verification via ‘devenv’ /NoVSIP command line parameter. I think the more likely scenario I see is having people to contribute to the project and I build the releases or betas.

And, I'm settings aside the whole loosing control over the project issue. That bothers me to some degree too.

Hope this long rant was informative.

[zythra]

Expect to see a new beta posted this weekend.

You're awesome man! I hope others tell you that too so you know how much your tool is appreciated.

And, I'm settings aside the whole loosing control over the project issue. That bothers me to some degree too.

I can understand that. You've put a lot of work into this and it wouldn't take long for the "right" people to ruin it. Quite honestly, if you never feel like opening it up, there's really nothing wrong with that, I don't think you'll ever lose users over it, least of all none of the users I know.

[Sergey]

You're awesome man! I hope others tell you that too so you know how much your tool is appreciated.

Thank you, I appreciate it. FYI, new beta with disabled search delay is out.

Quite honestly, if you never feel like opening it up, there's really nothing wrong with that, I don't think you'll ever lose users over it, least of all none of the users I know.

I just don't think the product is at that point yet. When number of feature requests or their complexity overwhelms me then I think is the good time to consider asking for more help or OS. We'll see how it goes. BTW, good example of a successful free and yet closed source project is 7-Zip.

dnk.nitro (if you're listening),

That search delay has been turned off by default. You can still enable it by adding DWORD 'SearchDelay' registry value to HKCU\Software\Microsoft\VisualStudio\<Version>\DPack, where as <Version> is 7.1 for VS.NET 2003 or 8.0 for VS 2005. Set 'SearchDelay' registry value to 1, restart Visual Studio and you should be good to go. HTH.

[zythra]

That search delay has been turned off by default.

I don't quite know what happened Sergey, but now with it off, it's even more painful than it was with it on. Every letter I type pauses for what seems like at least a half a second, maybe even a full second. Before the delay was ever introduced (before this new round of betas) I could type out my search term and the filtering kept up with my typing quite well.

I hope that makes sense, let me know if it doesn't.