XPO 7.1 RTM - news about delayed properties, and a (potentially) breaking change

Before you panic: this change is unlikely to actually break anything for the large majority of XPO users. Let me describe.

Following a suggestion from a user, we implemented support for delayed properties in our simplified property syntax scheme. Looks like this:

  
  [Delayed]
  public Byte[] BigPicture {
    get { return GetDelayedPropertyValue<Byte[]>("BigPicture"); }
    set { SetDelayedPropertyValue<Byte[]>("BigPicture", value); }
  }

As you can see, there’s no explicit storage variable used in this example. This is basically case (2) from my description of the variations of simplified property implementation. For delayed property implementation this is the recommended syntax from XPO 7.1 onwards – the one disadvantage outlined for case (2) was the absence of the local storage field. This is not a disadvantage for delayed properties, as the storage field itself (the one of type XPDelayedProperty) wasn’t any use for the programmer anyway.

So what’s that about a breaking change?

There are two important details that may change your application’s behaviour to some degree:

1. Setting the delayed property value now fires an OnChanged event – a good thing, but a change nevertheless.
2. For the change notification, the old value of the delayed property will be fetched from the database if it hadn’t been fetched previously.

Note: This change is only in the final 7.1 version of XPO, not in the RC that is currently available.

Free DevExpress Products - Get Your Copy Today