I have a control MyButton that inherits from Button and implements an interface that I created (IMyButton). This interface has some extra properties that I want to use on the button. But I also need the .net property 'Name' so I add this property to the interface (DEF PUBLIC PROPERTY Name AS CHAR...).
Now I use the MyButton on a form. When I loop through the controls on this form I can succesfully cast this object from System.Windows.Forms.Control to MyButton. But when I refer to the 'Name' property I'll get the error: Could not access element 'Name' of class 'IMyInterface' using object of type 'MyButton' - compilation is out of date. (12882).
This is probably due to the fact that I defne the property as CHAR but within the .net control it is defined as a System.String (which I cannot use).
Anyone any suggestions on how to overcome this problem?
Anyone any suggestions on how to overcome this problem?
I recommend to delete all R-Code first and then recompile the Interface and the class. I doubt it's due to your "Name" property of the System.String datatype.
We usually use a batch file to remove all R-Code and run that as an external tool from OpenEdge Architect before doing a full compile.
Thanks for you quick reply. It's not the .r code though. Even without compiled sources I will get the error. I recreated the error in the simple example I described, so there are only three sources: IMyInterface.p, MyButton.p and SomeForm.p
My feeling is that the error mentions 'compilation' because the OEA kind of thinks that the .net Control should be compiled again (because it uses the System.String and not the CHAR).
alex_u4a wrote:
Thanks for you quick reply. It's not the .r code though. Even without compiled sources I will get the error. I recreated the error in the simple example I described, so there are only three sources: IMyInterface.p, MyButton.p and SomeForm.p
My feeling is that the error mentions 'compilation' because the OEA kind of thinks that the .net Control should be compiled again (because it uses the System.String and not the CHAR).
Remember, ABL always compiles, even when running on source code.
I've run into a similar issue before, which was partially fixed in 10.2B (according to the bug, at any rate). You should report it to tech support (although your issue sounds more like another bug - OE00171291 - than the one I ran into).
-- peter
Thanks Peter, bug OE00171291 is actually a lot like what I am experiencing. The only difference is that I'm not accessing the property directly on the inherited control, but that I'm first casting it from .net control to my ineherited ABL control.
Your bug seems to be fixed indeed, because if I change the specific line of code it does work.
I will report it as a bug.