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.

 

[JackTheC]

Just found out that the same behaviour occurs in VFP9 but not in VFP3.
So if you guys have commercial applications with read-only grids i suggest that you check these for unwanted and unexpected changes by users.

 

[Mike Lewis]

Jack,

I followed your steps exactly (in VFP 9.0), but I can't see this behaviour.

Are you certain that the integer value is being stored in the table? How are you checking that? Could it be a SET DECIMAL issue, or something similar?

I tested this with the In_Stock field in the Tastrade Products table. I manually set it to 12.345 (with a REPLACE). I then followed your steps.

I then did ? In_Stock. It still contained 12.345.

I then re-ran the form. The original value was still there.

There must be some other factor at work here.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JackTheC]

Mike,

I used a free table.
Style Professional or Embossed doesn't matter i noticed.

If the grid is NOT read-only this behaviour does not occur.
But then again the users can change the records intentionally and that's what i want to prevent.

if you set the read-only property of the grid to True then the
records are changed to integers as soon as you move to an other record.
But only if you move the cursor with the arrow keys to the left or the right in that record in the grid and then up or down to leave that record.

You can check this by browsing the table. 12.345 has changed to 12.000 without the user typing any key other than the arrows.

I did this on 2 PC's (with XP on VFP6 and VFP9)
Soon i will try this on a Vista PC, but the OS may not have an influence for that matter.

I have set decimals to 2.

I think this is a serious problem, that's why i posted it. It corrupts all our precious data.

 

[JackTheC]

Just ran this test on Vista with VFP6: same error.

I don't know if the VFP9 version i used is completely up-to-date with the latest service packs and so.

Can you please do a test on VFP6. I have SP5 installed.

And another test proved that the old version of VFP3 is correct, that version does not change the values to integers.

So I think that versions 6,7,8 and original 9 have this problem.

 

[mjcmkrsr]

Jack,

I followed your steps exactly (VFP6 with SP5) but am unable to reproduce the behavior your describe.

As Mike said, you must have changed "something" else.

hth

Mark

 

[JackTheC]

Strange. I have this problem on all my pc's with vfp6 and vfp9 and xp and vista.
there is another thread on this site that reports the same problem but back then people could not reproduce it too.
I can reproduce it now on 5 systems, so how is that possible?

I think i will make a video for youtube....

 

[craigber]

You should never bind controls directly to the data. Following this rule, it's easy to have a read only grid. Populate it with a SQL Query and bind to the resulting cursor.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[JackTheC]

Just installed VFP9 on a second PC and updated it with SP2.
The bug has gone. So it must have been corrected with sp1 or sp2.
But applications in VFP6 - VFP9 original have this erratic behavior.
Whether this is wise of not wise programming doesn't matter. It happens and there are many applications out there.

Watch the video on Youtube

http://www.youtube.com/watch?v=4ir9GEAEcN4

 

[mjcmkrsr]

Jack,
I just watched your video and followed it step by step. No way to reproduce its behavior though (VFP6 and SP5) and (VFP9 and SP2). Maybe your VFP6 or some of its files are corrupted (Virus?).
hth
Mark

 

[Mike Lewis]

Jack, I feel sure you must have some unusual setting, or some other factor, that is affecting this. Or, you are doing something in your test setup that the rest of us are not doing.

If it is a bug that has been present since VFP 6.0, surely someone else would have noticed it by now.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JackTheC]

I cannot imagine that there is a setting that allows read-only records to change. A readonly grid is for showing records not altering them.

And i am not the only one:
This is a thread of somebody else last year

http://www.tek-tips.com/viewthread.cfm?qid=1607522&page=1

A virus? On all the PC's?I don't think so. Have scanner active all the time. A virus that affects only grids in VFP and doesn't work in VFP9Sp2. No.

Did you guys move the cursor to the left and/or right before leaving the field?

 

[mjcmkrsr]

Dear Jack,
I was able to reproduce the behavior your describe:
- create a table with one numeric field
- create a form and add a grid
- with the builder you add the table and the field and you select style (no matter which one)
- change Grid1.ReadOnly to .T.
- save
- run the form
- click on the DECIMAL portion of the number
- move the left and right arrow
- move the up or down arrow
the decimal portion of the number changes.

But asa you edit the form to change one single setting or browse the table and "correct" the data the behavior stops.

Mark

 

[Dan Freeman]

I cannot imagine that there is a setting that allows read-only records to change.

Picking a nit: Your records are not read-only. If you want read-only records, then USE table NOUPDATE.

Do not confuse a grid with the records it displays/edits. Data is not the same as the controls that display it.

 

[JackTheC]

Thanks mjcmkrsr for confirming.

VFP6Sp5. I changed properties of the grid and of the form and compiled it into an exe and the problem still occurs.

I have a program that does interest calculations for each day in a year. So 365 records in a temporary table. I display the results in a readonly grid with a print button.
I could never imagine that these results could accidently be tampered with.
So i think it is possible that many applications have the same problem.

 

[JackTheC]

Thanks Dan, use table noupdate is a workaround for this bug.
But a bug it still is and you don't notice it until somebody accidently clicks a record (OK textbox) and moves the cursor.

 

[TamarGranor]

I haven't tested, but reading the thread, it sounds like perhaps this problem only occurs if you use the Grid Builder. That would be why most people haven't run into it.

If that's the case, and that sounds easy enough to test, then the question is what property (or something) the Builder is setting that most people don't touch.

Tamar

 

[mjcmkrsr]

Hi all,
There are at least several conditions required to reproduce the described behavior:
- one and only one N field - asa there are more than one, all's fine
- use grid builder - without gb - all's fine
- if you change column SPARSE - all's fine
- if you change text ALIGNMENT = Right - all's fine
Nevertheless under the very specific circumstances it happens and a bug it seems to be.
Mark

 

[JackTheC]

@mjcmkrsr wrote "one and only one N field - asa there are more than one, all's fine"

That's not my experience. I have an application with 15 N fields in the grid, some with 2, some with 4 or even 6 decimals. And all the columns show this strange, buggy behavior.

I even think this is one of the top most worst bugs i have ever encountered in 25 years of Fox programming. Worst than a crash.
When having a crash or any visible error you KNOW there is something wrong and can make a workaround. When Foxpro changes the data unexpectedly as in this case, you can only discover it by chance. It can have severe financial consequences.

 

[JackTheC]

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.

from "List of Fixes in Visual FoxPro 9.0 Service Pack 2":
VFP8: Textbox - Decimal portion of numeric value reset to 0 when TextBox with Alignment = 0 or 2 and ReadOnly = .T. loses focus

Even in VFP6 this happens.