--
You received this message because you are subscribed to the Google Groups "Thor, the Tool Manager for FoxPro" group.
To unsubscribe from this group and stop receiving emails from it, send an email to FoxProThor+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
For LIKE() to find a match, it doesn’t *NEED* a leading and trailing asterisk.
? LIKE( “?ELLO”, UPPER(“Hello”) ) && returns .T.
Now if you’re dealing with cursor fields of type C(?), then there are trailing spaces you need to deal with:
? LIKE( “?ELLO”, UPPER(“Hello “) ) && returns .F., has trailing spaces
? LIKE( “?ELLO”, UPPER(RTRIM(“Hello “)) ) && returns .T.
As it stands now, there is *NO WAY* to do exact match filtering in GF, even if that is specifically what the user wants.
For example, if I only want to see the results that are in the Init() method of the objects found, I can’t. The filter results look like this:
That’s because if I *DON’T* use wildcards, GF filters on “SOMESTRING” $ UPPER(FieldName).
If I *DO* use wildcards, GF filters on LIKE(“*SOMESTRING*”, UPPER(FieldName)), which is effectively identical to the $ filter above.
I can understand why GF would not do exact matches *BEFORE* we had the wildcard option. But now that we have it, I don’t understand why GF should offer all these great filter options, then restrict how much you can filter with them.
FWIW, this is how I suggest this should be implemented:
1. If “Use wildcards” is NOT check, use the old behavior:
“SOMESTRING” $ UPPER(FieldName)
2. If “Use wildcards” IS checked, RTRIM() the field and apply the filter as-is.
a. If there is no wildcard in the string, just see if they are exactly equal:
“SOMESTRING” == UPPER(RTRIM(FieldName))
*or, for consistency with 2.b.*
LIKE(“SOMESTRING”, UPPER(RTRIM(FieldName)))
b. If there IS a wildcard in the string, use LIKE():
LIKE(“SOME*STRING”, UPPER(RTRIM(FieldName)))
Anyway, I don’t want to beat this to death, but that gives the user complete control over how to apply the filters, and that seems like a good thing to me.
Thanks,
Mike
--
You received this message because you are subscribed to a topic in the Google Groups "Thor, the Tool Manager for FoxPro" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/FoxProThor/Viq0P5CdVTM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to FoxProThor+...@googlegroups.com.
Given that the definition of wild-card matching used throughout GF finds matches anywhere in the searched field, the phrase passed to LIKE() must use "*" both before and after any search field even when using wildcards.
Jim,
To clarify my position, I was not suggesting any changes to the main search. I think the behavior there is appropriate, and should remain as-is.
To me, the filter has a different purpose from the main search. I don’t consider it be inconsistent that its mask behavior isn’t identical, because I have different expectations for a filter. The purpose of the main search is to FIND, and SHOW, as many results as possible, because I don’t necessarily know all the places my search string is referenced. But once I can see the results, I use the filter to HIDE all the results that I now know do not apply to whatever I am working on. For the main search, I want to INCLUDE everything that might be relevant. For the filter, I want to EXCLUDE as much as possible.
Does that help?
Thanks Jim, that seems like a good compromise. Whether in the caption or a tooltip, you could probably say something like "apply wildcard string exactly as written". I'm in no hurry, so whenever you get to it is fine with me.
Mike Potjer