There is a problem with the retention of data when you use field validation and one of those fields fail. I include the command I use for my field validation.
The scenario goes like this, every field that does not have some type of properties is refreshed after the error is displayed, field 3,10,11,8,and 9 will loose their content after the error is displayed, so beside having to fix the field in error, in this case I have to retype whatever I had typed in fields 3,10,11,8 and 9.
There is no problem with the fields you edit, it's the fields that you don't edit that loose data. if you look at the editflds command above, all the fields with no validation properties or date calendar properties are the ones being blanked out.
The data is lost when the magic field validate error is displayed, see the attachment
First of all, you say that it's the fields that you don't edit that lose data. Well, in the online example shown below, even if you don't edit some of the fields and cause a validation error, NONE of the fields get wiped out.
Secondly, there seems to be a difference between the way we're doing the validation and what you're doing. We're using the "super validator" or ASPdbValidator.jar. It does *client side* validation. This way, the fields turn red the instant an invalid keystroke is made, and a popup error message (customizable of course) pops up when they try to submit. It doesn't blank out any fields.
Can you verify that you've got the jar file in the jars folder, etc?
Try this, just dont select a shipper from the dropdown and input all the other fields, you'll see they will all get blanked out after the error message is displayed.
<script language="vb" runat="server">
Sub Page_Load(Source as Object, E as EventArgs)
Dim Update As New Tornado.Z()
With Update
.dbUnit = 777
.dbMode = "type=grid"
.dbSkin = 3
.dbDSN = "nwind"
.dbSQL = "Select * From orders"
.dbGridDisplayFlds = "0,1,2,3,8,9,10"
.dbTextHolder = "Test Blanking out of data"
.dbBookMark = "orders;0"
.dbValidatorParams = "code=/tornado/Jars|entry=false"
.dbFilterFlds = "0,1,2,4,5"
.dbEditaddFlds = "fi=0,fi=2,1,4,5,fi=8|ty=selectbox+b|val=CID|tex=C ID|oper=NB|comp=dummy|ErrorText=Shipper required,9,10"
.dbNavigationItem = "basic5,search,showall,add"
.dbCommonTables = "index=CID |sql=Select companyname from shippers order by companyname"
.dbLookUpFlds = "fi=companyname|key=CID"
.ASPdbNET()
End With
For SuperValidate (client side) the values never changed as it stays in the client side browser. For server side validation like MagicValidate the values are changed back to the original values. If update then the updated values are restored to the records origianl value. For "Add" unless there is a default, the original values are blanks. If we need to restore to thelast set of values and suppose there are defaults for all the inputs. Then which set is to restored to? Changed set or default set?
To me, the only way that makes sence is to retain the changed values, I have never seen systems where the user has to re-input all the fields that pass edit validation because he had one field in error. Default values on add should be set on the first pass only and populate the input fields to create an initial changed set that would be used until the transaction passes all the edits.
My add template has 42 fields, and only one of those field has a default value.
I think I luck out on this one.. turns out this 'retention' is already done in the grid edit. Obviuosely editing a grid of inputs and one magicvalidate error requires inputting the entire grid caught my attention before and code was made to retain the input. I copied the code to the standard setup and test your code and it works OK. So Supervalidate fields are not tocuhed and Magic Fields are re-populated. I'll do more checking before release.
Reply With Quote