Read-Only Grid DOES changes values 2

[JackTheC]

I just noticed that decimal values in my read-only grid do change values in the underlying database anyway.

Steps to reproduce:
I have VFP6 (don't know if other versions have the same problem)
Create a new form
Add a grid
Open the Builder

Add a table with a numeric field with decimal places with filled values in it like 12.345

add that field to the grid
choose Style Professional (this is important)
close the builder
make the grid readonly
do the form

Click in the record with that value of e.g. 12.345
move the cursor to the left or the right with the arrow keys of your keyboard without changes the value.
When you leave the record the value becomes an integer value and loses the decimal values.

The underlying table has changed in spite of being a read-only grid.

 

[Olaf Doschke]

I've been following this, but couldn't reproduce or otherwise add something helpful to this thread.

Ok, it's fixed in VFP9 SP2. That's explaining, why I don't see it.

I can only say that I haven't ad problems with lost digits in 10 years starting from vfp6. I believe you see that in vfp6, too, so the bug might have been longer around. It does have some bad impact,true. Perhaps most users of my apps were only moving the cursor in fields they also edited, therefor the loss of decimals was overwritten by the new value anyway.

I don't want to say it's not worth the discussion, but it's finally fixed and you can't expect any other hotfix for any previous VFP version, not even for VFP8. Even VFP9 is out of the support phase for additional service packs.

There is an obvious workaround in not binding numeric fields, instead manually set value and write changes back to the source field.

Bye, Olaf.

 

[Dan Freeman]

The problem is even more widespread. It also happens with normal textboxes on a form as long as readonly is .t. and alignment= 0 or 2. When moving the cursor the controlsource (table or memory variable) loses the decimal portion. If you don't move the cursor only the display is affected but not the controlsource.

That's truly unfortunate, but I'm not sure how much of an issue it is. I've been using VFP since the first alpha release was given to a very small group and have never had a problem with it. And that's a good thing since we're unlikely to ever see a fix for it (since it's already fixed).

You've found a situation where "it hurts when I do this" so your doctor would tell you "don't do that".

 

[JackTheC]

Just consider it a warning. When i opened the discussion i didn't know that it was fixed with the latest service pack of the latest VFP version. I do most of my programming in VFP6.
Furthermore you don't have any control over what your users do. You can say don't do that, but when you have thousands of users all over the world that's not possible. So programmers using older versions than vfp9sp2 should be aware of this bug and repare or workaround it. Nobody expects a repare from MS, so the programmers have to be on guard. readonly is not readonly!

 

[Olaf Doschke]

Three workarounds:

1. dont' bind numeric fields
2. use the table with the NOUPDATE clause
3. select into cursor nofilter or readwrite.

ad 1: instead manually set value and write back to the source
ad 2: this IS readonly on the cursor level
ad 3: even with readwrite this does not write back to a table

Bye, Olaf.