Filters and Grids

[stanlyn]

Hi,

What would allow records to show on a grid that a filter excludes. The grids record source type is alias. When applying a filter the grid is updated properly with the expected records. As soon as I scroll the grid, I begin seeing records that are outside the filter's scope.

Thanks,
Stanley

 

[Olaf Doschke]

Yes Mike, I would encourage that, too, but also already said it's a lot more to refactor. But keep that in mind.

Playing a bit with SET FILTER TO IsNull(_vfp.DoCmd("? SECONDS()")) that even prints out seconds() values while I do nothing, merely a browse window having focus prints three seconds() values in a row each second. That's pointing out how often the filter condition is tested to be true, even when resting on a row already checked. I assume it's a way VFP ensures to catch something changing the current row, although with my experience editing something only reflects in a removed row after leaving it, not only when a cursor is in a buffering mode.

SET FILTER is a bad toy.

Bye, Olaf.

 

[stanlyn]

Hi Olaf and Mike,

I did do the SET FILTER TO IsNull(_vfp.DoCmd("? SECONDS()")) experiment which raised some question that you answered in your last post. Thanks for that, and as you suggested, I was thinking that setting a filter was done and evaluated only once. I see now that it is not... Thanks for that as I've never read about that before.

Now, I've also heard that "set filter and public vars are a bad idea. I really don't agree because for one, as I just said, once I got the variable's scope set where it stayed in scope by making it public, the set filter works perfectly. My most compelling reason is their tie to the underlying data that enables in-grid editing with no coding. I've been using them for 15+ years with no issues. That is why I said I'm embarrassed to admit why I had overlooked such an obvious mistake, (but I guess others also didn't catch it). In the early days, I created form variables to hold these values instead of public variables. Then I started using global objects such as _screen that persisted everywhere, and then I realized that a public variable is just that, but much easier to implement and change and was in-scope everywhere. I can release it at will and create at will. So today, I use public vars a lot. It just makes sense. In the old days when consumption of memory was an issue, it may??? have made sense, but not really because having a variable attached to a global objects is also using sys resources. At least I can create and release as needed. I would need a compelling reason to go back and do it the way I did early on. I'm all ears...


I also use code like
select field1, field2 from dbf order by field1 into cursor curStates
to populate comboboxes, where data is read and not edited.

You can solve that either by programatically updating the underlying table when the form closes (or when the user hits a Save button); or by using a local view to populate the grid (a local view is essentially a cursor with some wrapping that enables it to sync to the underlying table)

I would be interested in knowing how to do some of this as my early days of working with views were all negative, therefore I avoided them. My early experiences with them was with big data and it took way to long compared to using set key or set filter when appropriate indexes were used.

Thanks, Stanley

 

[atlopes]

I'm curious to see how you would write my filter below that uses a value of a textbox.

lcFindValue = thisform.txtFind.Value
set Filter To table.party1_name = lcFindValue

something like this (not tested, but I think the idea is simple to implement):

lcFindValue = '"' + strtran(thisform.txtFind.Value, '"', [" + '"' + "]) + '"'
set Filter To table.party1_name = &lcFindValue

that is, a literal is always in scope...

 

[stanlyn]

Hi atlopes,

So why wouldn't
lcFindValue = "'" + allt(thisform.txtFind.Value)
set Filter To table.party1_name = &lcFindValue
work as well? Why is strtran() needed?

Thanks,
Stanley

 

[Olaf Doschke]

The moment you have a single quote inside lcFindValue aside of the ones you add at beign and end, simply imagine what happens with macro expansion.

Let's say you have O'Tool in lcFindValue, then add outer delimiter quotes - 'O'Neill' - and finally do SET FILTER TO party_name='O'Neil'

That fails. Just look over into thread184-1769629

Bye, Olaf.

 

[Mike Lewis]

Stanley,

Regarding public variables. I don't belong to the school that says you should never use public variables. I do use them in a very limited way. In particular, I use them to hold references to global service objects that I want to call on throughout the application. For example, my Settings object, which enables me to store and retrieve system-wide settings at any point.

But I am very much against using public variables on the fly, in the way that you have done. If you just create a public variable for a specific short-term use, you run the risk that it will clash with other variables that you have created, perhaps in distant parts of the app - something that is almost certain to bring disaster.

In my own apps, I have adopted the following rules: (i) Use a naming convention that clearly indicates that a given variable is public; (ii) Declare and initialise all your public variables in the same place, near the start of the application; and (iii) Don't use public variables unless you can find no obvious alternative.

I'm sure many forum members will disagree with me, and say that you should not use public variables under any circumstances. That's fine. I won't argue with that. My rules reflect my personal preferences, but I would rather err towards not using public variables at all than using them too freely.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[stanlyn]

Hi Mike,

I too have adopted very much the same rules that you use. Public vars defined and assigned a starting value based on their type at the top of my _main.prg. lcSomething is local char and gcSomething is global/public char. goCrypt is a global/public cryption object and on and on.

I always use local first and then private if the var must survive a trip across a couple objects such as forms or reports.

Even when I need the var in form2, I normally call the form as do form with parm1, parm2, etc. This is how I normally work, however I've quit adding custom properties to the form unless absolutely necessary. I guess some would say that this is necessary...

For example, my Settings object, which enables me to store and retrieve system-wide settings at any point.

I use a local table for that, because I can persist changes across shutdowns. You use the word "store" above. Are you saying that you can write values to this object at runtime that persists. If so, I would like to know more about how to implement, as I can get rid of the only dbf in the app which is "settings".

Thanks,
Stanley

 

[stanlyn]

Hi Olaf,

The moment you have a single quote inside lcFindValue aside of the ones you add at beign and end, simply imagine what happens with macro expansion.

Yes agreed, I had not thought of all the input possibilities...

Thanks, Stanley

 

[Mike Lewis]

I use a local table for that, because I can persist changes across shutdowns. You use the word "store" above. Are you saying that you can write values to this object at runtime that persists. If so, I would like to know more about how to implement, as I can get rid of the only dbf in the app which is "settings".

Using an object in this way is not an alternative to using a DBF. You still need a physical storage medium for your persistent settings.

The DBF is the medium in which the settings are stored. The object is the mechanism for saving, retrieving and managing the settings.

One of the aims of an object is to hide the details of how it works. My Settings object happens to use a DBF. But it could equally use the Windows Registry to store the settings. Or perhaps an INI file. Or maybe some other medium that I haven't thought of yet. The point is that that choice is hidden from the outside world. The object's user (that is, the application which calls on the services of the object) doesn't know or care anything about DBFs or the Registry or whatever. It only has to give the object the settings that it wants to store, and to ask it to retrieve the ones it wants to read.

I hope this makes sense.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[torturedmind]

Are you saying
this.parent.parent.txtUserName.value = "UserName" - can produce going out of scope???

whereas
thisform.txtUserName.value = "UserName" - would NOT cause the going out of scope???

What I meant was if "THIS" is used on the right side of the filter expression.

kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."