S
Simon L. Prinsloo
Guest
I guess he wants to do the same thing as I (and most likely many others) frequently dream about: Bind the properties of an object directly to the display. I've created my own type descriptors in the past to bind class properties to the screen, but it is quite painful. I've also seen at least two other implementations which use serialized data that ship with the code do provide these descriptors. In all cases you also see a custom dll, most likely because of the road block I describe below. First of all, it is a lot of work. You have to implement your own type descriptor and your own type description provider, which you will need to register with .Net. You will also need custom property descriptors andnattribute descriptors as well. Further more, when the property in the ABL object changes, it must implement the IComponent and INotifyPropertyChanged interfaces from .Net, so it is no longer portable. I normally work around it by implementing a portable version to call an empty protected method, passing the property name, in the setter and then inherit on from there, purely to implement the .Net interfaces and to override the empty method with one that Publish the required .Net Event. Back then we were still on our own with serialization, but as that have no impact on the implementation of the .Net interfaces, that was not a problem. Of course serialization will now most likely move back to you, despite the improvements we got in 11.6, as the derived type with the UI support is not the same as the portable base type. At one point in the process you will hit a roadblock: When .Net tries to update the bound property. I cannot quite remember the details, but it had to do with the following method in System.ComponentModel.PropertyDescriptor: public void SetValue(object component, object value) Initially it seems that you simply need to inherit that object and overided the method with this: DYNAMIC-PROPERTY(component,THIS-OBJECT:Name) = value. Where THIS-OBJECT:Name is the name of the ABL property represented by this type descriptor. Of course, you will have to check the type of your property and UNBOX() value if it is a native type. I can't remember exactly what went wrong here, but it had something to do with the Value-Types. What I do remember is that I figured out, from the stack traces generated in the error object, that there was a back and forth boxing and unboxing when Value passed through the bridge and it ended up crashing at the point where the CLRBridge it tried to invoke the on the OpenEdge side of the property descriptor. I eventually resolved it by creating an abstract C# class, inheriting from the System.ComponentModel.PropertyDescriptor, to serve as the base for the OpenEdge based property descriptor in order to be able to pass proper native types through the bridge.
Continue reading...
Continue reading...