All:
Gentlemen, thank you. MCRO (My cup runneth over).
Here's what I gather:
1. CFAs facilitate the development and standardization of well-structured code;
2. CFAs make it really easy to find and see a related family of routines within their context (anyone who's programmed in APL really appreciates this);
3. CFAs allow a single code instance to support multiple points-of-use within a form; and PROPERTY calls from without. A side benefit comes from eliminating the error inherent in chasing down and editing multiple instances spread across EEPs within one or multiple forms;
4. CFAs facilitate 'remote access' by PROPERTY calls from other forms' CFAs or EEPs;
5. CFA property calls can be 'daisy-chained' or 'nested';
6. CFA code is readily available for extraction via the Editor.
7. CFAs serve as a central 'window' for calls to VARCHAR routines contained in regular tables, or code in stored procedure files or app files. I'm taken by Brad's suggestion of a further abstraction and centralization of OPTION values as part of that process.
This is all very timely for me, and I appreciate it no end. Kudos to the R:Team for making all this happen.
Yours,
bruce chitiea
safesectors inc.
Bill Downall:
I like to use CFAs, organized by actions that ought to happen on
the occurrence of a particular event. For example, a CFA for what
happens when the "client ID" is set or changed, and another for
what happens when the "client type" is changed, and another for
what happens when the "preferred shipping method" is changed.
Then, code can be reused in multiple places in a form without
having to repeat it.
Then, of course, the "client type" control on the form has to have
an EEP that runs PROPERTY RBASE_FORM_ACTION CFAname ' ', etc, but
the same PROPERTY command may also be in an "Initialize" EEP on
after load, and/or on row entry.
Jan Johansen:
My vote is for Custom Form Actions. They become part of the appli-
cation and can be called from elsewhere like:
PROPERTY RBASE_FORM_ACTION MyMenuForm|CalledFormAction ' '
note : your main menu form would need the componentid MyMenuForm
Emmitt Dove:
Like Bill I prefer CFAs in particular for modularity. Often I will
have a CFA that is called by other CFAs which may have in turn been
invoked by another CFA. I will add one advantage - all the bits of
code are there in one place for you to see. You don't have to go
searching through all of the various actions on all of the controls
on the form to find something.
Lawrence Lustig:
1. For actions that occur once and only once, and only in one form,
I'm willing to use an custom EEP.
2. For actions that occur only in one form, but at different times,
I always use a custom form action (and call it from custom EEPs
when needed). Because, in my experience, #1 type actions often
turn out to be called more than once (eg, AFTER START and as the
result of one or more user actions), I often just skip #1 and go
straight to a custom form action.
3. For code that is used by more than one form, it goes into a
stored procedure or APP file and is called from the custom EEPs
that use it.
Mike Byerley:
Additionally, if a CFA is likely to be used across more than one
form, the code can be consolidated to a VarChar field in a table
and use the RUN SELECT command to access it from the form either
in the CFA or EEP...
Brad Davidson:
And further to "RUN SELECT" method, I have found a time saver for
application-wide revisions if for example, all pause, dialog, and
choose OPTIONS are coded in one location (VARCHAR ). All I need do
is change the THEMENAME to appreciate the global revisions
throughout my applications... I look for every opportunity to use
this process where/when ever I can. I suppose stored procedure
method is similarly appreciated.
Doug Hamilton:
SFWPOH!
I forgot that CFAs could be called from another form. I store RUN
SELECTS in an InternalCode table cuz they could be called from
anywhere. So compare CFA vs RunSel:
RunSel: If you're in form designer, you don't need to close the
form and open MenuForm to edit (due to poor planning ;) or create
a "global" CFA.
Portability to a new db - toss-up? Generic MainMenu with CFAs vs
unloading InternalCode table & importing into new database.
Incremental updates from test db to production: Cut & Paste for
both?
Security against unauthorized editing and prying eyes? Probably
CFA. more...?
I like to use CFAs, organized by actions that ought to happen on
the occurrence of a particular event. For example, a CFA for what
happens when the "client ID" is set or changed, and another for
what happens when the "client type" is changed, and another for
what happens when the "preferred shipping method" is changed.
Then, code can be reused in multiple places in a form without
having to repeat it.
Then, of course, the "client type" control on the form has to have
an EEP that runs PROPERTY RBASE_FORM_ACTION CFAname ' ', etc, but
the same PROPERTY command may also be in an "Initialize" EEP on
after load, and/or on row entry.
Jan Johansen:
My vote is for Custom Form Actions. They become part of the appli-
cation and can be called from elsewhere like:
PROPERTY RBASE_FORM_ACTION MyMenuForm|CalledFormAction ' '
note : your main menu form would need the componentid MyMenuForm
Emmitt Dove:
Like Bill I prefer CFAs in particular for modularity. Often I will
have a CFA that is called by other CFAs which may have in turn been
invoked by another CFA. I will add one advantage - all the bits of
code are there in one place for you to see. You don't have to go
searching through all of the various actions on all of the controls
on the form to find something.
Lawrence Lustig:
1. For actions that occur once and only once, and only in one form,
I'm willing to use an custom EEP.
2. For actions that occur only in one form, but at different times,
I always use a custom form action (and call it from custom EEPs
when needed). Because, in my experience, #1 type actions often
turn out to be called more than once (eg, AFTER START and as the
result of one or more user actions), I often just skip #1 and go
straight to a custom form action.
3. For code that is used by more than one form, it goes into a
stored procedure or APP file and is called from the custom EEPs
that use it.
Mike Byerley:
Additionally, if a CFA is likely to be used across more than one
form, the code can be consolidated to a VarChar field in a table
and use the RUN SELECT command to access it from the form either
in the CFA or EEP...
Brad Davidson:
And further to "RUN SELECT" method, I have found a time saver for
application-wide revisions if for example, all pause, dialog, and
choose OPTIONS are coded in one location (VARCHAR ). All I need do
is change the THEMENAME to appreciate the global revisions
throughout my applications... I look for every opportunity to use
this process where/when ever I can. I suppose stored procedure
method is similarly appreciated.
Doug Hamilton:
SFWPOH!
I forgot that CFAs could be called from another form. I store RUN
SELECTS in an InternalCode table cuz they could be called from
anywhere. So compare CFA vs RunSel:
RunSel: If you're in form designer, you don't need to close the
form and open MenuForm to edit (due to poor planning ;) or create
a "global" CFA.
Portability to a new db - toss-up? Generic MainMenu with CFAs vs
unloading InternalCode table & importing into new database.
Incremental updates from test db to production: Cut & Paste for
both?
Security against unauthorized editing and prying eyes? Probably
CFA. more...?
