GoFish 5.0.136 Beta Update

[Jim Nelson]

Two further enhancements:

[1]  There is a new filter option, "Only show first match in each PROCEDURE", sibling of the option released last week, "Only show first match in each STATEMENT".

[2]  Some of the column headers with been slightly re-worded, and the selection page for them in the Options form has been cleaned up a bit:

--

Jim Nelson

(805) 498-9195 (preferred)
(720) 837-3536 (cell)

www.kongcompany.com

[Mike Potjer]

Hi Jim,

I don't know if this is new to this build, but I noticed that if I'm using a mask in the filters, GoFish is adding extra asterisks to the beginning and end of the search string.  Here are some filter settings I entered:

And here is how they are being applied.

Where I already have an asterisk at the beginning and end of the string, the asterisks GF is adding are redundant, but they don't change the outcome.  However, if the string begins or ends with question mark or explicit character, then the outcome is not what was specified, as you can see in these results:

The highlighted file name does not match either filter as they were specified in the filter form, since it has more than 2 characters before "aca", and does not include "1095".  I actually changed my original filter because I noticed what GF was doing, and wanted to test it, so this was not actually a problem for me.  But ISTM that if I specify wildcards, GF should trust that what I entered is what I really want, and not add to it.

Thanks,

Mike

[Jim Nelson]

Mike --

That's what it's supposed to do, actually.  Since you are using wildcards (? or *) in your filters, GF has to use LIKE(), which recognizes those wildcards.

But, for LIKE to find a match, you need leading and trailing * -- without them you would be looking for exact matches.

IOW, using leading or trailing ? or * in your filter is (and should be) ignored.

--
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.

[Mike Potjer]

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.

[Koen Piller]

Mike,

if it came to a voting, I vote for your solution.

Regards,

Koen

[Jim Nelson]

Mike --

I should have said:

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.

This should already be familiar territory, since the main search field in GF allows the use of wild-card matches (mine is always turned on), and it find matches anywhere in the field.  (If you don't use any wildcards, there is no difference between plain searching and wildcard searching.)  I would not even consider changing this so that wild-card searching would require the user to enter a leading and following *; this feature has been around in Beta for a long time and I can see no good reason to change it now.

The use of wild-cards in filters should be completely consistent with this.  The user should be able to enter "THIS" in the search text, whether the wild-card checkbox is on or not. (Again, mine is always on).  It would be entirely inconsistent to now require that somebody either turn off the checkbox or using leading/trailing * because of the feature change you are proposing.

I am not saying that what you are asking for should not be available, but to do so the proposed change must allow the current UI to work exactly as is.

[Mike Potjer]

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?

[Jim Nelson]

Does your explanation help?  Yes, it does.  I understand your position.

My position is that I am not going to make any changes to the filter form so that something that has been working until today stops working tomorrow.                      

The definition for the filter text boxes, whether wild card searching is on or off, has been to find matches anywhere. I cannot simply pull the rug out from current users who are accustomed to that behavior to accommodate your new request, especially since I see that request as the unusual case (I have never found the need for this. nor has anybody brought up the topic before today --and the filter textboxes have been around for quite some time).

[Jim Nelson]

Mike --

I would like to be able to satisfy your request on this issue without disturbing the current behavior.

I believe that this can be accomplished by adding a checkbox on the filter form with caption "Exact Match" (or any other caption you think more relevant).  This checkbox would be visible and relevant only when the "wild cards" checkbox has been selected.  You could leave this checkbox always on, for your uses, and others could simply choose not to use it if they prefer the current behavior.  I suppose, though, it would need a tooltip to clarify what "Exact Match" would mean.

If this works for you, it would be quite straightforward to implement, although I would not be able to look at it until the end of next week.

On Fri, Jul 29, 2016 at 12:18 PM, Mike Potjer <pot...@gmail.com> wrote:

[Mike Potjer]

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