vfp 8 form with grid, modify with parameters, current record fields blanked 1

[clyderose]

I have a form with a grid and buttons. It is used to look for and select a record. In the Init, parameters are passed by array to set up the grid and the buttons appropriately for the current DBF being Added, Edited etc.
Whenever the Do Form is activated, the fields of the current record of the DBF that correspond to the controlsource for the columns in the grid are replaced with "".
What a surprise.
Any help would be appreciated.
Thanks

 

[clyderose]

Yes I know that ANYTHING can be forced to display in a grid.
The issue and the concern is that the GRID saved data to a table on its own volition.

Clyde

 

[Olaf Doschke]

Well, even if the grid is readonly and you expect it to not put a .Value="" into the controlsource, isn't it quite clear this is the problematic part of your code.

Readonly rather is about disabling interactive change of the control, it's not preventing programmatic changes of values and it's also not disabling the inner working of the controlsource writing back to the table. Putting a field in paranthesis does exactly that, as I explained previously.

So is that resolving the questions.

You may not like the way it is defined, but even outside of a grid, make a control bind to a single field, make it readonly, and it only prevents interactive user change, not programmatic changes.

If you now have he question, why it only affects one record, then you don't yet have learned the concept of the grid. It only has the one control per column, it only draws them multiple times, so only one, the active record, is blanked by the .value="" lines.

Bye, Olaf.

 

[clyderose]

Ah, finally I understand! Sometimes it takes awhile.

The only guaranteed way to make a grid completely readonly is to make the column1.controlsource an expression instead of a field.

To me readonly meant READONLY! I don't allow editing in a grid, I always have the user highlight then click an edit button which opens a separate form, locks the record and this is then buffered and a "Save" and "Dump" button to write the data to the table or dump the changes. That seems to be the best way to preserve data integrity.

My having the .value="" in my original code was a result of cutting and pasting from another routine. Just plain sloppiness on my part. I am just experimenting with this form for this application.

Still, the blanking of the fields in the table was quite a shock.

Thanks to all of you for the input, and have a great day!
Clyde

 

[Olaf Doschke]

Well, using a readonly cursor would also turn the grid really readonly, eg query INTO CURSOR without the READWRITE clause, or use a non updatable view or cursoradapter. Or a dbf with readonly attribute set should also make the grid go "fully" readonly.

Grid.readonly is just a control.readonly, the recordsource itself determines, if it's writable or not. And value is still bound to controlsource in both directions.

Using an expression (field) is just disabling writing by "tricking" VFP to think it couldn't write back, even if it tried, it's perhaps still the easiest way to enforce a readonly usage of the controlsource.

Bye, Olaf.