Getting properties of class

Not in the same way as for procedures. You can get something out of the XREF. That's what we use for generating documentation (together with method comments).

My assumption is, that OEA parses the source code (AST) - at least to build the outline view.

Doing it in code is probably going to have to wait for enhanced reflection (is that anything like polishing the mirror?). Of course, you could use the proparse.jar ...

Is this now possible in 10.2B ??

Not any better than in previous releases.

Well, ain't that a pile of poo.

Unfortunately not.

-- peter

Consider it a safety precaution to keep you from doing reflection and dynamic programming.

Consider it a safety precaution to keep you from doing reflection and

dynamic programming.

That's too funny: no dynamic programming in the (our) 4GL? Um, yeah, OK.

-- peter

It has its place, but is heavily abused, especially in terms of dynamic calls that make it impossible to create a callgraph for an application.  Clearly, dynamic queries are essential for some things and there is a place for some other things in frameworks, but I think too many people reach for it all too quickly and produce unreadable, unanalyzable code.

I am trying to create a enum-type class where the valid values of the

class can be loaded into a combo-box or selection list . I can do this

by creating a method that adds all the property names into a string

but wanted to do it automatically.

Julian

On 16 March 2010 21:13, Thomas Mercer-Hursh

So, this is internal to the class, not something accessible from outside?

You really should look into code generators.  That would make this sort of thing automatic without requiring any dynamic features.

I'm not sure what I think about each enum value being its own property.

>>So, this is internal to the class, not something accessible from outside

Yes. It should be a single property that returns all possible values

of the "enum"

>>You really should look into code generators.

I was

>> I'm not sure what I think about each enum value being its own property.

This ensures that if you refer to this value anywhere in code it is a

valid value. I've been bitten many tomes my mispellign a value (e.g.

">Actoin" instead of ">Action"). Having Event:Action instead means

that it won't compile if I misspell or mistype. I used to use

preprocessors for this purpose.

Julian

On 16 March 2010 21:34, Thomas Mercer-Hursh

I'm not sure what I think about each enum value being its own property.

What else (given the out of the box capabilities of 10.2B)?

Admittedly, I haven't thought a lot about this yet, but I suppose I was thinking of something more like IsValid(test value) and ToString(sample value) working against a list rather than each value being its own property.  I suppose that exposing it as a property means that you can do a type-safe assignment which is a plus, but if you have a possible value which has not been verified, it seems like you need something like IsValid() to test it.  Are you doing both?

In any case, I would rather solve it with a generator than dynamic code.

Are you doing both?

Yes.

In any case, I would rather solve it with a generator than dynamic code.

Seems like overkill to me. Most enums have a hand full of values.

I agree, a generator is the way to do this. At the moment, I don't

allow free-form entry of values that are part of an enum, so access is

only by combo-box / selection list etc so the user can only choose a

valid value .

Julian

On 16 March 2010 22:00, Thomas Mercer-Hursh

Admittedly not a major labor saver, but it certainly takes less time to provide the list of values and press a button than it does to type all the options.

Depends on your level of trust.

I.e,

MyClass:EnumProperty = MyEnum.SomeValue

is very safe, but

MyClass.EnumProperty = something from a combo box which I am presuming was populated with the possible enum values

is less safe.

True. That's why there is a validator method.

Julian

On 16 March 2010 22:21, Thomas Mercer-Hursh