Grid displays the same values for ALL records.

[rlawrence]

I'm working in VFP7 on sub-classing a grid to make it easier to dynamically assign a new table to grid's RecordSource without losing all of my column settings. I'm following the basic outline seen in several articles--some on this forum.

i.e.

Save your column properties somewhere
Set grid.RowSource = ""
cNewTablePath = <Path to the new table>
Set grid.RowSource = ["]+ cNewTablePath + ["]  && This was a hummdinger!
Set grid.RowSourceType = 0 && Because it defaults to 1 if you don't. @#$%^&*!!!
Restore column properties from somewhere

I finally have all of the working pretty well. I'm still struggling with the initialization of the grid. But the real problem I'm having now is that the grid displays the same values for every record in the new table!

More specifically, the grid seems to display the number of rows corresponding to the number of records in the new table, but each of those rows contains values from the current record pointer in the table--generally record 1.

I hate grids...

A little debugging and I find that if I open the table separately (in the same datasession) while my grid is still visible, the grid will display the values associated with my current record in the table. I move to a new record and reactivate the grid, and voila! All the records display the new values. Pretty slick, huh? Not very useful though.

I don't think it has any bearing on the problem, but the column properties that I am saving and restoring are:

grid.columns[n].controlsource
grid.columns[n].width
grid.columns[n].header1.caption

Yes, I am going to the trouble of specifying the alias for the new table as I restore the controlsource properties. Refreshing the grid doesn't help.

Can anyone give me a hint at what I am missing? What could possibly cause the grid to display the same values for every record in the collection?

And why the heck is it so darn difficult to dynamically assign a table with the same structure to a grid. To be honest, I have never found the other RecordSourceTypes to be very useful either. I'm thinking of going back to BROWSE.

Thanks in advance for your help,

Ron

 

[Olaf Doschke]

grid.RowSource = ["]+ cNewTablePath + ["] is already questionable. You open a table and typically use alias rowsourcetype.

UT has downloads of grid storing their controlsources etc.

Also with a grid what works best is a view, you can requery a view without breaking the grid, without storing it's properties. Even not using a view, you can use a cursor, query new data into a secondary cursor, then ap the grid cursor and append the new result.

The grid displaying the same value in all rows is typical for non sparse columns, if you preset another control and also if the grid itself is not bound to the alias the controls are bound to. Then the grid scans the grid alias, while controls repeatedly show the value of a current record of some other alias.

Bye, Olaf.

 

[Mike Lewis]

Ron,

No doubt this is just a typographical error, but are you sure you mean RowSource? Listboxes have a RowSource; grids have a RecordSouce.

Also, what is the ControlSource of the columns set to? If it is something in the form "alias.field", then are you sure the alias matches that of the specified table?

My point is that, if the RecordSource is 0, VFP will open the table behind the scenes, and assign an alias to it. Most of the time, that alias will be the same as the root table name, but it might not be (for example, if the table name isn't a legal alias). If it isn't, that would explain the behaviour you are seeing.

It would be better if you open the table explicitly (with an ALIAS clause if necessary), then set the RecordSource to the alias, and set the RecordSourceType to 1.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Yes, I meant RecordSource. Sorry. Not the first time I've done that, but there is no typo in the code for this property anyway.

As for using a view, there really is no need for a view in this context. The framework I have developed presents data in a temporary table. It would be a lengthy explanation, but the idea is to keep editing local and database accesses which are potentially remote to a minimum. The long and short of it is that the data to be presented for editing is in it's own temporary table.

 

[Mike Lewis]

Well, I would still consider my suggestion that you explicitly open the table, and set the RecordSource to its alias.

By the way, you might also find this article useful:

Controlling grid data dynamically

although the solution it suggests might be more complicated than it needs be.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Also, the quotation marks around the path to the table came from a suggestion on a previous post:

http://www.tek-tips.com/viewthread.cfm?qid=1254874

I can't explain why this should be necessary, but it seems to be. Without the quotation marks, the assignment of the new table path doesn't seem to work.

My framework assigns this temporary table a name using SYS(2015). The temporary tables are also stored in an assigned Temp path, to keep them together, and to make garbage collection easy. So, a typical path to a temporary table will be something like:

C:\Users\Ron\Documents\PubAssist Data\Temp\_30W102Z9I.DBF

This path is already assigned to a string property of an object by the time I assign it to a grid's RecordSource property. Why I should need to surround it with quotation marks for the assignment to the RecordSource property completely baffles me--even with the space in the path. This is old and reliable function. From my pseudo code above, a command like...

USE (cNewTablePath)

...would have no problem at all. But assigning it to Grid.RecordSource does not seem to work without the quotes.

 

[Mike Lewis]

Ron,

You need the quotes because there is a space between PubAssist and Data.

In general, it's best to avoid spaces in paths and filenames if possible. They can cause many minor problems.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Hi Mike. Nice article. Thanks for the pointer.

O.K. I replaced my assignment of the table path with...

This.RecordSource = ALIAS()
This.RecordSourceType = 1

...and it worked.

Once again, I am left with the frustration that I don't understand why the use of the table (RecordSourceType = 0) doesn't work. I thought by using this setting I would leave the task of opening the table to the grid class code. I tried both closing the table and leaving it open after the assignment. (sigh) I'm sure that question will arise again the next time I need to make use of a grid.

Anyway, it seems to be working. Thanks for your help.

 

[Mike Lewis]

Ron,

Glad to hear it's working.

Do take note of my point about spaces in paths and filenames. I'm not completely sure if this contributed to your original problem, but it might well have done.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[rlawrence]

Thanks again. Point taken; but I have dealt with spaces in paths since the beginning of time. I basically assume the path is GOING to have a space in it somewhere.

Generally speaking, if the path is already in a string, then assigning it to another string is not a problem. Like I said above, USE (cNewTablePath) will work just fine--as long as the path points to a real table. The assignment to the RecordSource property seems peculiar.

So, exploring a bit more... when would you use a RecordSourceType of zero? What and how does the grid class attempt to open and close the table? Again, I would think that assigning the full path to the table and letting the grid control "do it's thing" would be the preferred method. I find myself asking a similar question every time I make an attempt to do ANYTHING with a grid using any of these RecordSourceType settings.

Did I mention that I hate grids?

 

[Mike Lewis]

Ron, I don't think setting the RecordSourceType to 0 itself causes a problem. I suspect the problems arise if VFP gives the table an alias which - for whatever reason - doesn't match the alias in your ControlSource properties.

That said, I have to admit that I never use a RecordSourceType of 0. I nearly always create a cursor for populating a grid, and in that case there is no choice; you've got use the alias as the RecordSource.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

I already said setting the recordsource this way is questionable. Nevertheless I found it working, eg also opening the table. Only a space in the path makes quotes necessary. This is rather futile though, if you use an alias, which can be anything, a table, a view cursor (local or remote), a cursor created by sql or create cursor, a cursoradapter cursor.

The one thing that can cause a difference in controlsource and recordsource is a space in the dbf filename itself. Spaces are allowed in the dbf filename, but foxpro opens such a dbf with underlines in place of spaces.

Cd GetEnv("Temp")
Create Table "my table.dbf" (id I)
* notice using alias my_table instead of "my table".
insert into my_table values (1)
insert into my_table values (2)
Use
_screen.AddObject("grid1","grid")
_Screen.grid1.Visible = .t.
_screen.grid1.RecordSourceType=0
_screen.grid1.RecordSource=["]+Addbs(GetEnv("Temp"))+[my table.dbf"]

Does open the table and works. But you'd not want to do this, GUI is GUI, business logic is business logic and data access is data access, and gui shouldn't do data access directly, especially not open tables. Should it? At least not, if you want to comply with a three tier design.

Bye, Olaf.