Open Laevos opened 8 years ago
Actually, I just realized this, but having the asterisk at the end of the string produces the same results as not having it there at all, so it currently doesn't seem to serve any purpose. I also can't use it in the middle of a string, such as CT*Test to get all of the central test servers (when it should list CT01Test, CT02Test, etc.).
The code is somewhat fubar for that feature. I would not rely on any predictable behaviour. It might have been prematurely pulled. There are some code quality issues but the intended behaviour does not appear to be well defined either.
I'm not sure how you can get *something to work without a crash so I guess somewhere there's a try catch or something that wipes out the filter on the exception.
A starting * or * will not work. Period, asterix and space are all treated the same, they are just separators for keywords to search. [ or , will be stripped from search patterns. The keywords are always wrapped in %%. ab means item contains a and item contains b.
It's not actually globbing.
https://msdn.microsoft.com/en-us/library/system.data.datacolumn.expression(v=vs.110).aspx
Wildcard characters are not allowed in the middle of a string. For example, 'te*xt' is not allowed.
It is trying to break around that but badly.
It needs to be reimplemented :(.
I see. It certainly looks like reimplementation might be the best option at this point, yes. Oh well, I suppose I'll probably continue to keep my use of the search feature to a minimum for now, then. Thanks for the advice.
I have a local patch. I believe it should be kept reasonably simple. What kind of behaviour would you like to see?
I currently have it so that , is a separator for patterns that all must be matched. a,b means a and b. The first item matches start with (item). If you want "ends with" you have to do: ,endsWith
Anything after the first item must have the leading and trailing wild cards given otherwise it is an exact match.
You can turn the first item into match anything with: *contains
Any wildcard not at the beginning or end of a section is exact matched. Spaces are not trimmed. If you want to match a literal % or * at the end or beginning of a name you can't.
comma is escaped by doubling so that ",," will be treated as literally "," and ",,,," as ",,". In the case of an odd number of commas, the last will be split.
There appears to be no quick and easy way that isn't a kludge to allow for matching patterns with wild cards in the middle for that particular UI component.
I think contains rather that starts with would be better intuitive behaviour for the first item but after that nothing is intuitive. A help popup could offer syntax and explanation of current pattern.
What are your thoughts?
@joeyhub I think at a minimum "" should match 1 or more wildcard characters, "?" should match only 1 wildcard character. I am not sure it needs to be more complicated than that unless of course the RegExp option is selected in options, then well it should pass that on to the regexp engine to handle. "" should be implied at the beginning and end, for example of I have the following hosts in my session list:
the search term "er" should match 3 and 4 "bar" should match 1 and 2 "r?" should match 1, 2, 3, and 4 "r?." should match 3, and 4 it should honor the options -> GUI -> Search preference
currently it appears to work as described without the * or ? characters
Linking to the related discussions happening in issue #547
I'm having an issue with the new * wildcard feature (SuperPuTTY 1.4.0.7 on Windows 8.1 64 bit). When I put it at the end of a string, it works more or less as expected (more on that in a minute). However, if I instead try and use the wildcard at the front of a string, it returns every server. For example, I have a server saved named Laevbox. If I search for "Laev_", it comes up as the only result. However, if I search for "_box" (or anything with the asterisk at the front of the string), it returns every single server that I have saved, none of which but that should match that query.
Additionally, although placing the asterisk at the end of the query works, it does so only if the first part of the string is the beginning of the server's name. Using a different example, my employer uses a set naming/numbering standard for our servers including timezone and number. So there are several servers basically of the form [Timezone][0-9][0-9][Location]. If I search for, say, 09*, all of the servers containing numbers are listed.
Hopefully this provides adequate information to determine the problem; feel free to ping me if you need any further specifics, thanks.