Setup: NoesisGUI 4.0.0 Indie for Unity, Unity 6000.5.8f1, Studio opened inside Unity. The project file sits at the Unity project root, with DefaultDataNamespace set to "myapp", and the structures and data sets live in .noesis/data/structures and .noesis/data/sets.

Our screens are ControlTemplate resources in ResourceDictionaries. Their first child carries d:DataContext="JournalData", a Data Set of the structure myapp.Journal, which has a Lines collection of myapp.JournalLine. Opening such a screen in Studio works perfectly: the ItemsControl bound to Lines is filled, the rows are drawn with design data, and there are no errors.

Row templates are keyed DataTemplate resources used as ItemTemplate. For example, Journal.Line.Template is a Grid containing a few TextBlocks bound to Tick, Kind and Actor.

The problem is that opening such a DataTemplate from the Resources panel, in edit mode, gives it a string as DataContext. Every binding then logs two lines in the Unity console: "Binding failed: Path=Tick, Source=Boxed<String>(''), Target=TextBlock(''), TargetProperty=TextBlock.Text" and "Can't solve PropertyPath: Type 'Boxed<String>' does not contain a property named 'Tick'". With about fifteen row templates, this floods the console every time we browse the resources.

Here is what we tried, each result verified from the Unity Editor.log.

First, we put d:DataContext="JournalLineTest" on the template's root element, JournalLineTest being a Data Set of the structure myapp.JournalLine. Same errors. To see what the template actually receives, we added a TextBlock bound to the bare DataContext with a StringFormat of "ctx=[{0}]": it displays "ctx=[JournalLineTest]". So the attribute value is used as a literal string, not resolved to the Data Set. The same attribute on a screen's root is resolved correctly.

Second, we added DataType="myapp:JournalLine" on the DataTemplate. No change.

Third, we tried the Home icon in the Data panel, the one that assigns a Data Set to the current scope. It is greyed out when the DataTemplate is selected. If we move the row into a ControlTemplate resource, applied by a ContentControl inside the DataTemplate, and open that ControlTemplate, the Home icon becomes enabled: it writes exactly the same d:DataContext attribute on the root element and shows the blue badges, but the preview still receives the string.

Fourth, we tried a Data Set whose structure is not referenced as a collection SubType anywhere. Same result.

Fifth, we added FallbackValue to the bindings. The fallback is applied, but "Binding failed" is still logged.

So my questions are the following.
Is designing a DataTemplate with design-time data, outside of the page that hosts it, supported in Studio 4.0? Blend honors d:DataContext on the template root for exactly this case.
If it is not supported, what is the intended workflow, always editing item templates by opening the hosting screen and selecting a generated item?
And is there a way to avoid the binding-error flood in the Unity console when a template resource is opened without data?

Thanks.

Hello,

When editing a DataTemplate from the Resources tab you will enter the template scope without any context, and in that case we try to infer it from the DataType.

If you assign myapp.JournalLine as DataType we will automatically create a dummy instance of that type to be used as design data.
With or without DataType specified, if you assign a Data Set (of the expected structure type) when editing the DataTemplate, you will be able to see the values from that data set.
Can you verify if that works for you?

Hello sfernandez.
We verified both, restarting the embedded Studio before each check so that no scope cached from a previous edit could interfere.
We use the Studio embedded in the Unity 4.0.0 package.

Assigning a Data Set works. We created a set of the JournalLine structure in the Data panel, filled it with Generate sample data, opened the DataTemplate from the Resources panel and assigned the set with the Home icon.
Studio wrote d:DataContext="JournalLineTest" on the template root, and the preview shows the generated values, also after restarting Studio.
Our earlier failure with the same attribute was with a set file written by hand outside Studio; we suspect that is the difference, but we have not proven it.

DataType does not work for us inside Unity.
The Data Type dropdown lists the design structures under Design.myapp and writes DataType="myapp:JournalLine"
After restarting Studio, opening the template raises InvalidOperationException: Can't create an instance of myapp.JournalLine, default constructor is not available, from Noesis.Extend.CreateInstance, and the bindings then fail against Boxed<String>.
So inside Unity the name resolves to our C# view model, whose only constructor takes a DTO, rather than to the design structure, and the existing data set of that structure is not used either.

Should DataType resolve to the design structure when Studio runs inside Unity, or is a parameterless constructor on every row view model the intended requirement?

Finally, the console flood remains even in the working case.
Each time the template is opened, and once at Studio startup when it restores the document, the four bindings are first evaluated against the literal string of d:DataContext, which logs two lines per binding, and only then the data set is applied. Is that first pass expected, and is there a way to avoid it?

After restarting Studio, opening the template raises InvalidOperationException: Can't create an instance of myapp.JournalLine, default constructor is not available, from Noesis.Extend.CreateInstance, and the bindings then fail against Boxed<String>.
So inside Unity the name resolves to our C# view model, whose only constructor takes a DTO, rather than to the design structure, and the existing data set of that structure is not used either.

Should DataType resolve to the design structure when Studio runs inside Unity, or is a parameterless constructor on every row view model the intended requirement?

This is not the intended behavior, Studio should use the design type, not your C# view model. Could you please create a ticket in our bugtracker and we will fix this issue?

Finally, the console flood remains even in the working case.

We should not generate any binding error messages coming from Studio UI itslef, and we're fixing them as we find them.

Each time the template is opened, and once at Studio startup when it restores the document, the four bindings are first evaluated against the literal string of d:DataContext, which logs two lines per binding, and only then the data set is applied. Is that first pass expected, and is there a way to avoid it?

The messages from the design DataContext seem a different thing, could you also report that so we can investigate it?