>Overview:
>
>A way to hook into VFP's compilation cycle so that we can have our own VFP tools pre-process the source code received by VFP's compiler. This would allow developers to enhance the VFP language in a manner similar to that used with C++, i.e. "VFP++" source code would be translated to standard VFP source code which would then be compiled in the conventional way.
>
>Benefits:
>
>1. Ability to enhance VFP syntax without changing compiler or runtime engine (classic C++ strategy)
>
>2. Ability to detect simple semantic errors earlier in dev cycle
>
>3. Ability to detect simple problems, prompt for fix, and continue
>
>Note: It is possible to turn off auto-compliation for PRG files, and then use project hooks to do this for PRG files at project build time, but it is not possible to disable the AUTO compliation of method code in the form and class designers. The goal would be to allow a developer's own pre-processor to be available not only in PRG code editors and method editors, but also in the Command window as well.
>
>Implementation:
>
>

>SET PREPROCESSOR TO mypreprocessor.prg
>
>and/or
>
>_PREPROCESSOR = "mypreprocessor.prg"
>

>
>Details:
>
>If a preprocessor application is registered via one of the above techniques, it would receive the "enhanced" VFP++ source code that VFP is preparing to compile as a parameter, pre-process this source code, and return raw VFP source code to the native VFP compiler. If the pre-processor code detected critical errors, it would return .F. to cancel the compilation event.
>
>Example:
>
>_PREPROCESSOR = "myPreProcessor.app"
>
>* example function header - update pcSource by reference
>function myPreProcessor( pcSource as String ) as Logical
>
> ... pre-process code here ...
>
> * update source being processed by reference
> pcSource = [pre-processed version of source]
>
> * to cancel compilation return .F.
> return llSuccess
>endfunc
>
>Conclusion:
>
>This "seems" like one of the easier type of Sedna enhancements to implement as its essentially a single hook into in an existing process. This enhancement does not impact the VFP compiler itself, nor does it require any changes in the VFP runtime.
>
>Malcolm

I like this. I can see many advantages to have this operation.

It reminds me of GenScrnX or GenMenuX.