Question: Is there any way to have OEA define a preprocessor somewhere in its environment before it performs a syntax check or compile?
Background:
We are hoping to wrapper some code in existing .p files in a way such that it can behave differently if it is compiled in a product that uses .NET interfaces or a product that does not.
A simple example that illustrates the type of stuff we want to do is, displaying a newer looking message box that has additional features and uses a .NET form.
In the .p, we would like to do this at compile time using a preprocessor-- something similar to:
&IF DEFINED(USEDOTNET) &THEN
Common.AppMessageBox.Show("Bad Dog!","Error","Ok").
&ELSE
MESSAGE "Bad Dog!" VIEW-AS ALERT-BOX ERROR.
&ENDIF
For compiles done outside of OE Architect, this works fine, because we use our own compiler that can define the USEDOTNET preprocessor as needed before compiling.
But while working inside OEA, we are looking for a way to have the USEDOTNET preprocessor defined, without having to GLOBAL-DEFINE every .net class we have created.
&IF DEFINED(USEDOTNET) &THEN
Common.AppMessageBox.Show("Bad
Dog!","Error","Ok").
ELSE
MESSAGE "Bad Dog!" VIEW-AS ALERT-BOX ERROR.
DIF
This question might be better asked on the OEA forum.
But I have a counter-question: what's wrong with still using the MESSAGE statement? (I realise there might be other calls that work differently depending on USEDOTNET)
-- peter
In general I guess there are two ways to approach the issue: Preprocessor or making the wrappers clever enough to identify if the .NET UI functions are available at runtime.
I guess you need to test four things:
1. Progress Version >= 10.2A
2. Windows GUI operating system
3. GUI runtime
4. .NET CLR is present
OPSYS and PROVERSION can be checked with preprocessor expressions - just a little different.
GUI runtime is a session attribute (available at runtime, not compile time)
I guess the easiest way to check the presence of the CLR is NEW a System.Object and see it it fails.
But in a 10.2A OEA all this will probably always return TRUE... (unless you are compiling with a TTY runtime)
If you are already wrapping those functions, I guess I'd rather wrap them and make the wrapper clever enough to understand if the .NET UI is available at RUNTIME.
But I have a counter-question: what's wrong with
still using the MESSAGE statement?
We extended the functionality of the message statement, and styled it to look like the rest of our app. There are also different examples where we need to do the same thing that do not necessarily involve user interface.