With nearly 20 years of experience working with the product, researching and developing advanced projects for clients, finding new functionality to include in VFE, and general curiosity, I've discovered many undocumented workflows that can be leveraged and some that should be avoided. I've considered writing a 'book' from time to time, but for the last decade or so we have been hearing 'MEL is dead' with renewed emphasis on 'soon' each time I thought I would just go ahead with it . End result, it never happened.
Form load occurs in the following order:
In VFE - the 'MEL window' or right widow is processed first.
Any MEL code that leads with an exclamation point is processed.
All other MEL code in the window is processed.
All MEL code in the form proper is processed.
All form translation code is processed.
All form element display code is processed.
One important aspect of the 'order' that code should appear is an easy to remember positioning:
BOTTOM to TOP for initialization then TOP to BOTTOM for subsequent executions.
My standard workflow is (starting at the bottom of the 'MEL window'):
Declare all global variables with a ! character to ensure they are allocated an address in memory.
Declare all global DOCUMENT. variables with a ! to ensure they are allocated an address in memory.
Declare all functions with a ! character to ensure they are loaded into memory.
All of the above is below my 'watcher' expressions as they appear in the 'MEL window'.
Next I have my 'watcher expressions' (actionable code that begins with the ! character).
At the very top, I have my non-watcher actionable code.
I also avoid placing function definitions in buttons or form items for better control over when it is executed. In my experience this enhances form stability. Michael has done a lot of work to mitigate these issues by wrapping the code in a function of its own, but 'old habits...' ya know.
Other important notes are:
Referencing undeclared variables are a critical error for MEL. Always account for your variable names and be certain to declare them as local unless you specifically want them to be global. Unintended variable crossover is VERY bad and that includes loop counter variables!
Referencing a non-existent index in an array is a critical error for MEL. Best practice is to include an error trap buy evaluating the size of an array is at least a large as the highest index number you are referencing in the code. You can/should include a userok to notify the user/coder that the array size is not what was expected therefore the 'result' should not be 'trusted'.
When troubleshooting, understand that a single error can create the appearance that something else is broken. Fix code one issue at a time and retrace after each fix to save on headaches.
Some errors never reveal themselves leading to a false sense of 'it's working'. This is often seen in 'else' workflows that are less common in day to day practice. Always test the 'else' condition to be certain your code is working as intended.
Not the 'reference' you are looking for, but it is a start, right?
Posted : May 2, 2019 2:34 am