Using preprocessor names when compiling from OEA

You would need to define the preprocessor in an include file  (.i) as a global define (so the scope extends beyond the include file), and include the .i in your program.

OEA itself ignores preprocessors when working with code, so using them often ends up reducing functionality.  Could you explain more about what you are really trying to accomplish.  Perhaps there is another way to do what you are trying  to do rather than use preprocessors.

Could you explain more about what you are really trying to accomplish.  Perhaps there is another way to do what you are trying  to do rather than use preprocessors.

He (probably), myself (for sure) and others are looking for a substitute of the AppBuilder's

&IF DEFINED (AppBuilder_Is_running)

stuff. To be able to run programs that in the application require input parameters from the editor (for debug purposes) without having to go thru the main menu window. This preprocessor is used to alternatively defined input parameters or variables (with default/test values).

Actually, I was looking for a way to have a piece of code compiled for a certain custumer if he uses a certain module. If the module is not active then the code should not be compiled. There are other ways to solve this, but I'm dealing with existing code coming from Unix (where I could compile having preprocessors defined).

For now the problem is solved since customers working on Windows don't use this module. I can therefore use the preprocessor &OPSYS instead of the module name (&IF "{&OPSYS}" EQ "UNIX" &THEN)

I'm still interested in a solution though. Mike's gives a good example of where preprocessors would make sense.

First the rant:

[RANT]

OEA shouldn't be used as the build tool for your deployment code.  The generated r-code includes debug information as well as lacking MD5 checksums.  It is also generated out of a development environment that can change based on a developer's needs at the moment.    There are build tools such as PCT that are more appropriate.

[/RANT]

Now if you are only working with in a development environment that of course none of that is a concern .

There are some major differences in how OEA deals with r-code compared to how the AppBuilder deals with r-code.   In many cases what you run in Appbuilder is not compiled into r-code before it gets run.  Instead it gets run as source and compiled on the fly, so each time you run it, the preprocessors are re-evaluated so having special appbuilder preprocesors isn't an issue because it gets reevaluated every time.  The other major difference is that (usually...by default) when you run something in OEA, you start a completely new AVM.  It isn't the same AVM environment that is used to compile the r-code for the project, and once the new AVM is started (except for debugging) there isn't any much of an association between the AVM you started and the OEA environment.  Each launch configuration can be completely different and not even look at all like the project envrionment that is used for developing code.

You also have the issue of running code on an AppServer that may have been compiled from within OEA.  In that case there truely is a wide disconnect between the processes, and there is no OEA environment on the AppServer.

That said, there are some things you can check, but they are not preprocessor related.  If you are just doing some stuff with "test" code that won't make it into your application, then there are a few things you could do.

When OEA starts an AVM to run a program it sets a few environment variables.  You can test for these if you want your code to behave different in a development environment.

cWorkspace = OS-GETENV("ECLIPSE_PROJECT").

and a few others. Look in the program in debug.core plugin under the 'abl' directory if you want to find all of them.  These are guaranteed to change over time so you shouldn't use them for your application code, but for test code "anything goes".

There are only a couple of global defines that OEA uses for its own  purposes to setup some defaults for communication between the AVM used  for compiling, and the Eclipse process itself.  If you dig around in project plugin "runtime" directory the _server.p program might have something defined you could detect.  Again, this is subject to change, so making changes in that code would be unsupported.

The other way of course is to use include files that are specific to your development environment.  This way you have something you control, isn't subject to varying environments, and won't change unexpectedly.

None of this implies that this can't be done via an enhancement, but for now you can work around it using one of the above ways.

Thanks for you elaborate answer...