CodePath is empty (beta02)

[thomas.kilian]

Before filing a bug: has anybody else observed that CodePath (automation) does not deliver a value? I'm pretty sure it worked once :-?

[«Midnight»]

Regardless of "once" it should work now. Sounds like a bug to me.

[Eve]

Package.CodePath should give you whatever is saved in the database.  However, it isn't often written to by EA, so it will nearly always be empty.

The filename of a package that is visible via the gui is Package.Element.GenFile.

[thomas.kilian]

I might have omitted .Element (unfortunately it doesn't raise an error when an unknown method or attribute is accessed). So I'll try that later and I'll post the result.
Edit: Just tried it. Neither one does work. Will file a bug report.

[«Midnight»]

Package.CodePath should give you whatever is saved in the database.  However, it isn't often written to by EA, so it will nearly always be empty...

Still, this seems fragile. If the attribute is visible it should be dependable.

What happens (immediately and later) if you write a value to this attribute?

What happens if a user-supplied value conflicts with the GenFile attribute?

David

[Eve]

What happens (immediately and later) if you write a value to this attribute?

What happens if a user-supplied value conflicts with the GenFile attribute?

David

In a practical sense, this field is unused by EA.  (It's only ever set in two obscure places.)  It's then maintained by XMI round trip, and never used apart from the automation interface.

So, nothing happens if you write to it, and it won't cause any conflict.

[«Midnight»]

So a bit of clarification in the documentation should do the trick. [He hints slyly.]

[thomas.kilian]

Bugger - it's Package.Element.GenFile I actually wanted to have

Case closed.