Getting Started with dBASE - Claculations and field parameters for Procedure PRG files, dBASE 2.5

Author

Claculations and field parameters for Procedure PRG files, dBASE 2.5

Norman Snowden

2005-08-27, 1:23 pm

My programming involves only a small data base. However, each record requires about 15 enabled entryfield type fields to use for producing a fairly large number of calculated fields.

When form WFM fields are updated and saved this does not update the corresponding field in the PRG file. Why is this ?

It not very practical to pass parameters as e.g. Volume(form.rowset.fields["length"]. value , form.rowset.fields["width"].value , form.rowset.fields["depth"].value)

Similarly, in a long calculation requiring multiple parenthesis enclosures, division, raising to a power, etc. it is to difficult to acccurately type in or paste the values using form.rowset.fields["radius]".value etc.

As a result I assign Public memory variables to the fields, calculate in the PRG file, go back to the WFM Function and equate the actual field to the memory variableas e.g. form.rowset.fields["Savings"].value = _savings. It then has to be saved. (Can't s
ave it in the PRG file as in
Visual dBaseB 5.7). This is cumberson to say the least.

I have a long history with dBASE and love it. However, with minor improvements, if a 32 bit version of Visual dBASE 5.7 had been produced I think it would have been a big seller.

john marshall

2005-08-29, 7:23 am

Why not just assign the rowset to a variable to simplify your calls ...

cRow := form.rowset.fields

You can then call your functions ...

Volume(cRow["length"]. value , cRow["width"].value , ;
cRow["depth"].value)

JM

Norman Snowden Wrote:

> My programming involves only a small data base. However, each record requires about 15 enabled entryfield type fields to use for producing a fairly large number of calculated fields.
>
> When form WFM fields are updated and saved this does not update the corresponding field in the PRG file. Why is this ?
>
> It not very practical to pass parameters as e.g. Volume(form.rowset.fields["length"]. value , form.rowset.fields["width"].value , form.rowset.fields["depth"].value)
>
> Similarly, in a long calculation requiring multiple parenthesis enclosures, division, raising to a power, etc. it is to difficult to acccurately type in or paste the values using form.rowset.fields["radius]".value etc.
>
> As a result I assign Public memory variables to the fields, calculate in the PRG file, go back to the WFM Function and equate the actual field to the memory variableas e.g. form.rowset.fields["Savings"].value = _savings. It then has to be saved. (Can't
save it in the PRG file as in
> Visual dBaseB 5.7). This is cumberson to say the least.
>
> I have a long history with dBASE and love it. However, with minor improvements, if a 32 bit version of Visual dBASE 5.7 had been produced I think it would have been a big seller.
>

Norman Snowden

2005-08-30, 8:23 pm

Thanks John for the suggestion: cRow := form.rowset.fields. This would help. Unfortnately an error message : Variable undefined: crow occurred. Perhaps I did not apply it correctly.

john marshall Wrote:

> Why not just assign the rowset to a variable to simplify your calls ...
>
> cRow := form.rowset.fields
>
> You can then call your functions ...
>
> Volume(cRow["length"]. value , cRow["width"].value , ;
> cRow["depth"].value)
>
> JM
>
> Norman Snowden Wrote:
>
't save it in the PRG file as in[color=darkred]
>

John Marshall

2005-08-31, 7:23 am

Sorry, ... either define it, LOCAL cRow (you can name it a more useful name), or use the "=" when asigning the rowset, rather than the := which assigns the value, but does not create the variable.

JM

Norman Snowden Wrote:

> Thanks John for the suggestion: cRow := form.rowset.fields. This would help. Unfortnately an error message : Variable undefined: crow occurred. Perhaps I did not apply it correctly.
>
> john marshall Wrote:
>
an't save it in the PRG file as in[color=darkred]
>

Sponsored Links