Could not access element <foo> of class <bar> us

Let me see if I have this right:

You have a class B that implements interface A.

You say that if the variable is defined as class B then everything "works as expected." I assume that that means that there are no errors.

However, if you define that variable as interface A, then you get a runtime error that the compilation is out of date.

[1] Is it the case that the interface is not up to date?

[2] Is the problem that you are having that the error message says the class B is out of date and no interface A?

[3] It appears that the error is happening when trying to call the constructor -- or is it a method call that is happening from within the constructer?

This runtime error happens when the dispatch table that was created at compile time does not match the one it is executing against at runtime. This is the mechanism we use to call the methods, properties, etc. of the classes hierarchy. If you shuffled the members around, e.g. added or deleted members from either the interface or class, or even changed the order that they appear in the class, then at runtime we try to resolved these members by looking for them by name, etc. If we are unable to located a matching member then this error message is generated.

Hi Julian:

If you can provide Technical Support with reproducible steps, it would assist development with researching and resolving this issue.  Currently the bug number you cross referenced has no specific reproducible steps.  We have addressed issues like the one you are reporting in the past and need additional input to identity the specific case we still need to address.  Thanks

jmls wrote:
I have an interface class tftp (A) , and a class(B)  that implements (A), whilst inheriting a form.
I defined a variable as class A, and then tried to NEW it using class B, and I get this error (it has worked before, but in 10.2B01 I think), but we've upgraded to 10.2B04 and have since got this error.
If I define the variable as class B, then everything works as expected.
Anyone got any fixes ?

I do what you're doing all the time (define as IFace, instantiate as concrete type) in AutoEdge|TheFactory; lots of times across packages/projects in Architect. I haven't seen this bug in a long time.

But I have seen more general issues with bad/stale/something-not-quite-right r-code when using OEA, especially if I'm renaming programs and/or moving them around. I occasionally find that I need to run find . -type f -name *\.r -exec rm -f {} \; which clears out all the r-code. I then build everything via Project>Clean. I also run with the build automatically toggled off. I also make sure that the projects in my workspace build in the correct order; this I set up in Preferences > General > Build Order.

-- peter

Message was edited by: Peter Judge

Hi Alex,

1) The interface is up to date. I went so far as to remove all of the .r code and run from a 4GL editor session, and still got the error

2) Both the interface and class source files exist, and compile ok. A SEARCH() on the .r and .cls files from the editor session also give the expected locations

3) it doesn't get so far as calling the constructor.

I could send you the source files for both files if you want.

however, there is a slight wrinkle - if I new the class directly from the editor, it all works fine. If I run the application from the editor, then call a program which creates the class, it fails. I put a propath search on the .r files before I NEW the class, and get the expected results, so it's not that there is some errant .r hanging around

yah, it's the first time I've been bitten by it in such a long time.

However, this is not manifesting itself in the OEA - it's in an application runtime, or from a 4GL session.

Hi Julian:

Yes please log this issue with technical support.  It seems like you have specific steps that generate this error condition.  This info. will be very helpful to development.

Thanks

Evan