MFS programming standard (and Alpha) (AREV Specific)
At 20 DEC 2001 08:32:58AM Hippo wrote:
I am sorry, I am a dozen years later.
5 days ago, I 've read the knowledge base book dealing with MFS here in the site.
MFS is very poverful, I like its philosophy. Unfortunately the programming standard recomended in the book closes the doors for future updates.
The programming standard for a MFS doing nothing of the book says trap all 28 primitives.
In some cases call the following MFS in the chain and in other cases
set the STATUS to 1 and return.
Correct standard is: Call the following MFS in all cases when there is a following MFS otherwise set STATUS to 1.
This standard is opened for posible future extensions of the set of primitives. (I also hate updates, but why to close the doors?)
(First 5 MFS's (for the debugging purposes) I wrote according the recomendations, the CLEARSELECTGUARD.MFS I wrote according the new ones.)
(Of course I trap both READNEXT and CLEARSELECT. (Readnext on postorder when STATUS=0 immediately calls (RTP57.)CLEARSELECT) to be sure RBASIC does not violate the FMC. CLEARSELECT just returns with STATUS=1. This is better as it only changes timing, therefore it must be correct independently on what the CLEARSELECT realy does.)
At 20 DEC 2001 10:24AM Hippo wrote:
CLEARSELECTGUARD.MFS is not the final solution!
It correctly sets the alpha, (even if corrupted by previous SELECT),
but I obtain B802 Message
"89440 row(s) have been selected.
1 error(s) were detected."
What causes the apearence of the message?
Is there another interaction between RTP57 and RBasic?
I've only change the timing.
At 21 DEC 2001 05:43AM Hippo wrote:
When I modify the ClearselectGuard.MFS such that the timing corresponds to the expected one the problem with error messages disappear.
(Common variables are needed, therefore Install must be trapped, too)
Does it mean that the RTP57 is called somehow not through the MFS chain. Why? (Closed doors?)
At 21 DEC 2001 05:44AM Hippo wrote:
When I modify the ClearselectGuard.MFS such that the timing corresponds to the expected one the problem with error messages disappear.
(Common variables are needed, therefore Install must be trapped, too)
Does it mean that the RTP57 is called somehow not through the MFS chain. Why? (Closed doors?)
At 21 DEC 2001 06:22AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
All MFSs and BFSs are called independently by the system for codes such as Install so they can perform program specific functions.
World Leaders in all things RevSoft
At 31 DEC 2001 08:02AM Hippo wrote:
I am sorry,
the problem in AREV.EXE is probably only during the return from READNEXT with status=0. This is very fragil.
You cannot do even MSG(1). Therefore everything you want to do must be stored in common variables and performed during the following CLEARSELECT (which is not so fragil).
This may be explains the problems with timings.
But what explains the fragility?