UpdateRouteDataPoints not called

GoXam
1

I’ve created a custom part manager by deriving from GoXam.PartManager. In the constructor I set UpdatesRouteDataPoints = true. The CustomPartManager is hooked up in XAML as per the documentation. I have overridden PartManager.UpdateRouteDataPoints so I can push the points from the GoXam.Link.Route.Points property into the model and thus preserve them. This seems to work fine initially: I link two nodes, drag one node to cause a change in the Route, and then UpdateRouteDataPoints gets called appropriately.

Here’s the Route portion of my LinkTemplate:

<go:Link.Route>
  <go:Route Routing="{Binding Data.Routing}"
            Curve="{Binding Data.Curve}"
            Corner="10" />
</go:Link.Route>

However, UpdateRouteDataPoints is never getting called when I change the Curve or Routing properties. The display updates correctly and everything looks visually accurate, but my model is now incorrect. This is an issue for two reasons:

  1. Serialized model data is incorrect and will not reconstitute as it appeared on the screen. There does not appear to be a work around for this problem.
  2. The diagram exists in the Telerik equivalent of a TabControl. When switching tabs the PartManager is cleared as the diagram is unloaded from the visual tree. Setting Diagram.UnloadingClearsPartManager=False works around this problem.
This appears to be an issue only within the Silverlight version of GoXam. In the WPF version, everything works as expected and UpdateRouteDataPoints is called appropriately. Unfortunately WPF is a minor platform for me; Silverlight is the primary/major platform. Here's my system config:

OS: Windows 7 x64
Browser: IE 9 32-bit
Silverlight version: 4.0.60531.0
Visual Studio (2010) version: 10.0.40219.1 SP1Rel (there’s nothing after the “Rel”, not sure why that’s there)
GoXam Silverlight version: 1.2.2.4 (update: I downloaded an eval kit for 1.2.6.4, same result)
GoXam WPF version: 1.2.6.4 (not sure if WPF/SL verisons are supposed to be different; I’ve inherited this code so I’m not certain if they’re supposed to match)

To be clear, here are steps to reproduce at runtime:

  1. Open two tabs within a tab control. One should contain a GoXam diagram.
  2. Drag two nodes from a (non-Northwoods) palette.
  3. Drag from the first node to the second node to create a link. By default the Route is created with Curve=None and Routing=Orthogonal.
  4. Without moving either node, switch to the other tab item.
  5. Switch back to the tab item that contains the diagram. At this point PartManager.UpdateRouteDataPoints is called and the ortho route points are pushed into the model.
  6. Change the Routing property to Normal. (This is done via a toolbar button that updates the model property to which the route's LinkPanel.Link.Route.Routing property is bound.) The GUI updates to show a straight line instead of an ortho line. I would expect UpdateRouteDataPoints to be called here, but it is not.
  7. Switch to the other tab item again.
  8. Switch back to the diagram tab. UpdateRouteDataPoints is called for a second time, but it pushes the wrong data into the model. The link is displayed as an ortho line when it should be a straight line.
2

We’ll look into this soon. (It’s still the weekend here.)

3

Have you diff’ed the sources to see if there are any differences between the Silverlight and the WPF versions? Since you are using Silverlight 4, there should be very few differences in the XAML and none in the code-behind.

But there are a lot of differences in our implementation between the two platforms, so it’s possible that there is some subtle variation that we missed.

Your toolbar button that modifies the Routing property does so within a transaction, yes?

You’ve set Diagram.UnloadingClearsPartManager to false, yes?
Or is the “tab control” an actual TabControl?

4

I’ve made some significant changes to the flow control of this code. Previously various model properties were being set at odd times and in round about ways. It’s now all straight forward, well defined, and inside of a transaction. Everything now works, so this was definitely a bug in my code and not in GoXam.

5

I’m glad you got it sorted out. It wasn’t clear to me how we would be able to figure out what the problem was.