Hello:

We have given considerable thought to the following idea and would like your input, if you've got a moment to consider it. I'll try to keep the story short.

THEN: We have a "monolithic" FP DOS 2.6 application which has been
developed over the last 8 years. It has been debugged,
enhanced, evolved and improved about as far as it can be.
One improvement that we need, however, hasn't happened: it
isn't a Windows 32-bit product. Ugh!

NOW: We aren't in a position to do a rewrite (of any kind) AND
it will not run "as is" under VFP 6.0. What we have done is
construct forms and populate them with objects to simulate
the functionality of the DOS user interface.

IDEA: - Make NO modifications to the existing DOS code.
- Use the existing, complicated (and sometimes "spaghetti")
DOS code as a backend processing kind of module.
- Use the GUI that we have recently built to front-end the
application.
- Build an Interpreter between the two to communicate.
- The Interpreter we envision needs to do the following:
1- Respond to the objects on the forms or a menu choice.
2- Communicate to the DOS backend what needs to run.
3- Receive all output from DOS backend, including
screen directives, parameters passed, etc.
4- Return needed information (only) to the GUI front-end.

QUERY: Is this possible? If so, can you point me in the right
direction? How do we block unwanted DOS screen directives,
for example?

Thanks for your help!

David Powell
WagnerSys@aol.com