10.2B produces incompatible code with 10.2A

Posted by jmls on 03-Feb-2010 04:42

Just loaded a .cls form into the Visual designer of 10.2B. Made a couple of changes, saved. Moved the form to a 10.2A environment and it fails to compile .

The offending line in question is

DEFINE VARIABLE resources AS Progress.Util.ResourceManager NO-UNDO.

the prior code was

DEFINE VARIABLE resources AS System.Resources.ResXResourceSet NO-UNDO.

so this is a change automatically introduced by the Visual designer, but breaks compilation on any platform except 10.2B. Which is a bugger, as some of my clients are on 10.2A

Is there any way of turning off this new, bad, behaviour ?

Julian

All Replies

Posted by Admin on 03-Feb-2010 04:46

Is there any way of turning off this new, bad, behaviour ?

 

Use the 10.2A Visual Designer yourself...

Seriously - that's not the only difference between 10.2A and 10.2B, you might run into other issues (just thinking about the full support for .NET generic types etc.). When deploying on 10.2A, you need to develop with 10.2A.

Posted by jmls on 03-Feb-2010 04:57

Urg. I would expect that if I *chose* to use new features, then I can't expect to compile under 10.2A. But if all I am guilty of is loading and saving, then I *don't* expect my code to be made incompatible.

I am sure that this was not the case in the beta program, as I used 10.2B solely on my development machine, but carried on development for my production environment (10.2A), so I suspect a change was made before FCS but after beta.

Julian

Posted by Matt Baker on 03-Feb-2010 07:59

This was documented and was necessary to properly support localization of controls.  The existing code from 10.2A will still open in VD and will still compile and run as it did before.  If you "migrated" the form to 10.2B by editing it in the VD it will only write out new code.

The "new" behavior is correct and the "old" behavior was incorrect.  The class used by 10.2A (ResXResourceSet) is not capable of handling multiple .resx files and as such you cannot do any localization of the form.  In addition, it had other limitations such as throwing out some designer properties that were rather useful.  It also limits some runtime optimizations that could be done by using an alternate serialization mechanism that is supported by the new class (ResourceManager).

The VD in 10.2B will also write out multiple .resx files if you localize a control.  Previously it would throw out any alternate languages other than the one you were editing with when you saved the file.  The 10.2A VD cannot read and doesn't know how to handle multiple .resx files so if you localize a form in 10.2B, you wouldn't be able to read it back properly into 10.2A even using the old class because it would ignore the alternate .resx files.

Posted by Martha Lynch on 03-Feb-2010 09:55

We've recently come up with this 'statement' of compatibility (or non, as the case may be):
If you are using the Visual Designer to edit existing (created in a previous OpenEdge version) GUI for .NET code, the generated code will be updated to the current version of OpenEdge Architect.  Even if you believe you are not using new features from the current version, the Visual Designer-generated code may contain new language constructs that are not compatible with previous compiler and runtime (AVM) versions.   Therefore, the version of OpenEdge that you use to compile and execute that code must match (or be greater) than the version of OpenEdge Architect used for editing through the Visual Designer. 
We don't anticipate that this will change going forward. 
     -Martha

This thread is closed