GoWPF 3.0.3 - Issue with go:Diagram when used within a DataTemplate

Hi Walter, hope you are doing well, please see my issue.

I made a small demonstration application which looks like this:

On the left side, i set a go:Diagram as direct content, and on the right side i set the content with a DataTemplate which contains a go:Diagram.

For both, i used the same XAML code and within the XAML code, i also set my tools, for example a ClickCreationTool which creates a node on double click.

image

The problem is, that on the left side, all is working good, but on the right side, not a single tool is working. - The only difference is, that i use a DataTemplate.

I have to develop MVVM applications, and using DataTemplates is more less the state of the art way to go. - It seems like, there is a problem in GoXAM to work properly when used within DataTempates.

Please see my sample:
HannesHold/GoWPFDataTemplateIssue: GoWPF DataTemplate issue demonstration (github.com)

Currently, the only solution which i got to run correctly is, to make a CustomDiagram and creata all the tools needed, which are also CustomTools, within the constructor. - This means i have to do all in code behind, even have to set tool’s bindings, tool’s templates e.g. BoxTemplates in code behind of the tool’s constructor itself and so on.

I personally think this is a huge issue. - Can you please have a look at this, and let me know why GoXAM has this problem? - Maybe i am simply doing something wrong, and you will teach me better soon. - Many thanks meanwhile, Hannes

If you remove the settings of the go:Diagram.ClickCreatingTool and the go:Diagram.RotatingTool, does the template work?

Well, then i guess a default tool is used. - If i do not set the “PrototypeData” setting, then ClickCreatingTool does not work per default and i think this is intented, so i need to set it.

So in my sample, i cannot add a node, and therefore also not test this currently.
But from experience i can say, that it seems like then default tools with default settings are used when combined with DataTemplates.

I think what’s happening here is a basic flaw in XAML. That’s due to the conflict between the default constructor building a complex object including references to other objects and with setting those references to refer to different objects.

So in your non-template case, in XAML you are constructing a Diagram, which also constructs and references various other objects such as the various tools. Then your XAML replaces two of those referenced objects with new instances of the ClickCreatingTool and the RotatingTool (or subclasses thereof). Everything is OK.

But in the template case, the template has an instance of a Diagram and it has two of its properties replaced with your custom tools. But when the template is instantiated (“applied”) the copied Diagram does not get copies of your two custom tool instances. Instead I think it gets references to the same shared instances of tools. But that’s an error, since each Diagram has to have its own collection of tools and other objects such as PartManager, LayoutManager, and CommandHandler.

Ok. - On the internet i found a kind of similar problem, which i think we are also facing.

c# - Custom DependencyProperty set from DataTemplate - Stack Overflow

I am not sure if this is already a solution or not. - If i can do something to assist, just let me know.

Maybe define a custom control, inheriting from Diagram that initializes it the way you want. Possibly by overriding OnApplyTemplate.

This is what i am already doing in my companies application. - I initialize the tools in my custom diagram constructor and it is already working without the need to override OnApplyTemplate().

It is a bit unclear to me now, will you try to provide a solution to support DataTemplates in a more suitable way with a future update of the library? - Or is this closed from your point of view? - We already bought a licence fo GoXAM in the past and plan to buy another one, once the new applications development is done.

I can imagine, that a lot of people will run into such a scenario world-wide.
Of course for me both options are OK, i would just like to know where i stand, in order to plan future tasks.

Many thanks meanwhile, Hannes

No, we have no plans on making what might be incompatible changes.

Alright, thanks Walter for your support. - This is solved now for me.
Have a great week left and Happy Easter :)