Strategy Question

[awr]

In our application, I have several dialogs that contain some of the same
fields. Many of these fields require special handling or calculations, which
are generally handled through valid, action or on change clauses. In our
16-bit FiveWin version, I have had to copy the code for each field and
potentially change the resource ID when building new screens. When a change
is needed in the calculations or special handling, I have to search every
module for the field and update the VALID clause or ON CHANGE, ACTION code,
etc. This procedure is kind of a pain and prone to bugs if I miss one along
the way.
Is there a strategy that I can use to create a field repository that I can
inherit these special fields from? I've noticed the Calculated field usage
in some of the samples, but I am a novice so I don't know if this is the
right track. Basically, I want to give an edit field a field name that
contains the calculation logic in the on change or on exit events. This need
to be maintained in one location so I can reuse it over and over on
different screens.
I hope I am making sense. Any help you can provide is greatly appreciated.
Thanks,
Andy

[jfgimenez]

Andrew,
> In our application, I have several dialogs that contain some of the same
> fields. Many of these fields require special handling or calculations,
> which are generally handled through valid, action or on change clauses. In
> our 16-bit FiveWin version, I have had to copy the code for each field and
> potentially change the resource ID when building new screens. When a
> change is needed in the calculations or special handling, I have to search
> every module for the field and update the VALID clause or ON CHANGE,
> ACTION code, etc. This procedure is kind of a pain and prone to bugs if I
> miss one along the way.
>
> Is there a strategy that I can use to create a field repository that I can
> inherit these special fields from? I've noticed the Calculated field usage
> in some of the samples, but I am a novice so I don't know if this is the
> right track. Basically, I want to give an edit field a field name that
> contains the calculation logic in the on change or on exit events. This
> need to be maintained in one location so I can reuse it over and over on
> different screens.
>
> I hope I am making sense. Any help you can provide is greatly appreciated.
If I've understood correctly, you could use the AppData public object to
store codeblocks. Or even you could overwrite the TApplication class to add
your own methods for that purpose. Something like:
CLASS TApplication FROM XApplication
METHOD Validation1( oSender )
METHOD Validation2( oSender )
METHOD Validation3( oSender )
...
ENDCLASS
Later, you could assign the desired events directly in the object inspector
as:
{| oSender | Application:Validation1( oSender ) }
--
Regards,
Jose F. Gimenez
http://www.xailer.com

[aross]

You sort of have it and gave me some good ideas, but let me clarify a bit
more:
As I said, some fields in our system require calculations or special
handling. What I am doing with the 16-bit FiveWin version is passing a text
label from the field's VALID clause to a central calculation module that has
a giant DO CASE statement to process the calculation request.
VALID ( SysCalcs( "FIELD_NAME or CALC_ROUTINE" ), .T. )
FUNCTION SysCalcs( cCalcRequest )
LOCAL nResult := 0
DO CASE
CASE cCalcRequest = "FIELD_NAME" // One of many
nResult := SomeFieldBasedCalculation()
CASE cCalcRequest = "CALC_ROUTINE" // One of several
nResult := SomeGeneralCalculation()
...
ENDCASE
RETURN nResult
I suppose this is still a plausible way of handling field calculations. I
guess I need to figure out how to process and update the calculated fields
on the form. In FiveWin, I assigned the UPDATE clause to the fields in
question and cycled through all open "Forms" and processed oWnd:Udpate().
That way, view panels, data entry screens and any other controls presenting
field data are updated. I also added a check for open TWBrowse objects and
processed a oBrw:Refresh().
I was simply looking for a more elegant way of handling all of this in
Xailer.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> wrote in message
news:[email=44c9e5cc@news.xailer.com...]44c9e5cc@news.xailer.com...[/email]
> Andrew,
>
>> In our application, I have several dialogs that contain some of the same
>> fields. Many of these fields require special handling or calculations,
>> which are generally handled through valid, action or on change clauses.
>> In our 16-bit FiveWin version, I have had to copy the code for each field
>> and potentially change the resource ID when building new screens. When a
>> change is needed in the calculations or special handling, I have to
>> search every module for the field and update the VALID clause or ON
>> CHANGE, ACTION code, etc. This procedure is kind of a pain and prone to
>> bugs if I miss one along the way.
>>
>> Is there a strategy that I can use to create a field repository that I
>> can inherit these special fields from? I've noticed the Calculated field
>> usage in some of the samples, but I am a novice so I don't know if this
>> is the right track. Basically, I want to give an edit field a field name
>> that contains the calculation logic in the on change or on exit events.
>> This need to be maintained in one location so I can reuse it over and
>> over on different screens.
>>
>> I hope I am making sense. Any help you can provide is greatly
>> appreciated.
>
> If I've understood correctly, you could use the AppData public object to
> store codeblocks. Or even you could overwrite the TApplication class to
> add your own methods for that purpose. Something like:
>
> CLASS TApplication FROM XApplication
>
> METHOD Validation1( oSender )
> METHOD Validation2( oSender )
> METHOD Validation3( oSender )
> ...
>
> ENDCLASS
>
> Later, you could assign the desired events directly in the object
> inspector as:
>
> {| oSender | Application:Validation1( oSender ) }
>
> --
> Regards,
>
> Jose F. Gimenez
> http://www.xailer.com
>

[jfgimenez]

Andrew,
> You sort of have it and gave me some good ideas, but let me clarify a bit
> more:
>
> As I said, some fields in our system require calculations or special
> handling. What I am doing with the 16-bit FiveWin version is passing a
> text label from the field's VALID clause to a central calculation module
> that has a giant DO CASE statement to process the calculation request.
>
> VALID ( SysCalcs( "FIELD_NAME or CALC_ROUTINE" ), .T. )
>
> FUNCTION SysCalcs( cCalcRequest )
>
> LOCAL nResult := 0
>
> DO CASE
> CASE cCalcRequest = "FIELD_NAME" // One of many
> nResult := SomeFieldBasedCalculation()
> CASE cCalcRequest = "CALC_ROUTINE" // One of several
> nResult := SomeGeneralCalculation()
> ...
> ENDCASE
>
> RETURN nResult
Well, you may set the events like this:
{| oSender | Application:Validation1( oSender, "FIELD1" ) }
So, the first received parameter is the object that fired the event, and the
second is a constant string that could be the field name or so.
> I suppose this is still a plausible way of handling field calculations. I
> guess I need to figure out how to process and update the calculated fields
> on the form. In FiveWin, I assigned the UPDATE clause to the fields in
> question and cycled through all open "Forms" and processed oWnd:Udpate().
> That way, view panels, data entry screens and any other controls
> presenting field data are updated. I also added a check for open TWBrowse
> objects and processed a oBrw:Refresh().
>
> I was simply looking for a more elegant way of handling all of this in
> Xailer.
If you use datasets, you could benefit from the calculated fields, and their
associated controls are updated automatically. If not, you could simply
assign their cText or Value properties, and there is no need to 'refresh'
anything. However, if you need to update another controls in the same form,
you can use the oForm property to access that form:
FUNCTION Validate( oSender, cFieldname )
...
oSender:oForm:oDbfBrowse1:Refresh( .T. )
...
--
Regards,
Jose F. Gimenez
http://www.xailer.com