OE10.2B04
Let's say I have this include file:
/* test.i */
DEF PUBLIC PROPERTY {&Name} AS {&DataType} NO-UNDO GET. DEF PUBLIC PROPERTY Prop2 AS {&DataType} NO-UNDO GET. DEF PUBLIC PROPERTY Prop3 AS CHAR NO-UNDO GET. METHOD PUBLIC VOID {&Name}_method(): END METHOD. METHOD PUBLIC {&DataType} {&Name}_method2(): END METHOD.
And use it in a class:
CLASS class1 : {test.i &DataType=CHAR &Name=foo} END CLASS.
Now when I use this class, OEA auto completion (ctrl+space) reports the following members for class1:
Prop2 {&DataType}
Prop3 CHARACTER
{&Name} {&DataType}
{&Name}_method() VOID
{&Name}_method2() {&DataType}
The include arguments are not preprocessed, duh.
When I compile and save .r for class1, this works fine... but trying to keep .r up to date in a development environment gives me headaches.
So I was wondering if there is some settings in OEA that would allow this to work with uncompiled source, even if it slows down auto completion a bit.
10.2B doesn't resolve preprocessors. It ignores them. Anything defined like this would be considered syntax problems and couldn't be resolved without compiling the code. OEA also doesn't resolve include files as dependencies so changing the include file won't automatically recompile the referencing .cls file.
It looks like you are trying to create some classes that are based on generics, or a similar language feature model. The ABL doesn't support them natively, but you can use them with .NET for certain items. Trying to accomplish this with preprocessors is going to be chaotic.
> Trying to accomplish this with preprocessors is going to be chaotic.
Veto!
Works fine for me (for lists, dictionaries,...). I typically create an abstract base class and then the generic classes deriving from that that provide facades to the abstracted functionality using the desired data type, also using Include files with parameters in the derived class.
Using GUI for .NET hybrids is no option for me - as I want to use these collection alternatives on the AppServer (on non Windows platforms) as well. But I do always make sure I have compiled the code.
When that's an issue for Guillaume, maybe he can use two projects, one for the framework code (typically smaller and at one point in time more stable) and one for the application code. The first one should always be compiled, the latter one may not be that important to keep compilation up to date.
mbaker wrote:
10.2B doesn't resolve preprocessors. It ignores them. Anything defined like this would be considered syntax problems and couldn't be resolved without compiling the code. OEA also doesn't resolve include files as dependencies so changing the include file won't automatically recompile the referencing .cls file.
Same behavior in 11.0 ?
If you have a well defined set of collection classes such as lists, dictionaries, queues where you don't have to change any of them that's great. But until they are mature, and you have to change them regularly you won't get editor help or compilation help from 10.2B. I tested the example in 11.0 and it works.
11.0 resolves preprocessors. So if you develop without r-code this example does work.