Muliple grid pages

[erp84]

So the longer I stare at this the more I confuse myself.

I'm working with two grids, on two separate pages of a single pageframe. The grid on page2 is dependent on the record selected in page1.

The problem I'm having is if I build my cursors on the form.load the page2 cursor take forever because it's loading the entire dataset since at that point I don't know what record will be selected. Would AfterRowColChange be a good place to build the cursor, or is there a better place.

Sorry all, still a VFP rookie, and thanks for any help!

 

[Mike Lewis]

No,I wouldn't do it in the AfterRowColChange, because that will introduce a delay each time the user moves the pointer in the first grid - which they are liable to do many times per second.

Better to do it in the Activate of Page2. That way, the cursor will only be generated at the point that it is needed, that is, when the user decides to view the second grid.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

Would AfterRowColChange be a good place to build the cursor

You can't build a Grid's RecordSource dynamically once past the Form's Init Event.

If you tried to do that then when the Form was Loaded it would try to build the associated Grid with NO Existing RecordSource thereby causing things to crash.

If I need to do something like this I put my code in the Pageframe Tab Page Click Event so that when I enter the Tab Page I get what I want.

And for situations like this I have my Grid's RecordSource already in existence, but FILTER it in some manner based on the parameters in the other TAB pages.

A couple of approaches to putting a 'FILTER' on the Tab Page Grid records are:
* Have an Index build on the Grid's RecordSource Cursor with the FOR !DELETED() option and then DELETE all but that which I want to show.
* If the Cursor is not too large SET FILTER TO <whatever>

Good Luck,
JRB-Bldr

 

[erp84]

Mike, this works great, but how could I avoid "Activate" if they switch between tabs and haven't selected a different record on the main grid?

JRB-Bldr - The query for my cursor will take 60-70 seconds to run without any filters, so my users wouldn't like that each time they open up this form.

 

[Mike Lewis]

how could I avoid "Activate" if they switch between tabs and haven't selected a different record on the main grid?

Good point.

One possibility would be to create a custom form property to store the first table's record pointer. Initialise it to zero. Then, each time you go into the Activate, check the actual record pointer with the value saved in the property. If it is different, go ahead and build your cursor, then store the new record pointer. If the actual record pointer and the stored value are the same, do nothing.

Mike






__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

The query for my cursor will take 60-70 seconds to run without any filters, so my users wouldn't like that each time they open up this form.

What is better?
* Waiting for the data you need to populate a cursor?
* No Form at all because it would crash on Load trying to create a Grid with No RecordSource?

Maybe you can find a way to accumulate the data for the grid's cursor faster.

Another possibility would be to create the Tab Page Grid's RecordSource Cursor as an empty cursor in the Form's Load Event. That would prevent the Form from crashing on Load.

Then you could dynamically populate it with the needed data as the specific Tab Page was Clicked.
Although I'd guess that accumulating the specific data and Appending it to the Grid's RecordSource Cursor would itself take a not-un-noticable length of time as well.

Good Luck,
JRB-Bldr

 

[wtotten]

Mike's idea is what I use but you have to be aware of something. Since the grid will Init() before the form does (which means the grid can't "see" the custom form property at that point in the form instantiation), then your code cannot evaluate the form property (yet).

Using a filter on a grid, unless it is a small table, is a really bad idea most of the time because it's slow.
You can use the SET KEY TO but if you changed the controlling index on that grid's table, it would cause problems. Why would you want to change the controlling TAG; maybe the user wants the ability to sort on some of the columns. It depends on how many records are in the table of course. Sure, using a filter (or SET KEY TO) it can be an easy way of meeting a need, but it's bad programming (at least I think it is). All that being said, IF the table will only have a few thousand records and you can live with any constraints of SET KEY TO (or the unconstrained SET FILTER TO), then by all means use it.

In VFP 9.x you can use SET FILTER TO on a grid (set grid.optimize to .T.) and it uses Rushmore and you aren't constrained by the SET KEY TO command. Your gird will be fine even if there are a lot of records in the table provided you create your tags to take advantage of Rushmore. If the tags aren't properly create to take advantage of Rushmore, it will be slow if you get a lot of records in it.

BTW - you can call the grid's Init() after the form's Init() fires. It's rarely done though.

Bill

 

[Olaf Doschke]

For grid2, make the initial query with WHERE .F. or if using a view, set nodataonload .t.
In the form designer set bindcontrols to .f. and at runtime set it to .T. in init after grid cursors are ready.

Bye, Olaf.