Infralution Support

[EntityDev]

One more, please, before I knock off for a Saturday...

I was having a devil of a time with the VirtualTree and its editor, until I realized that setting a datasource for the VirtualTree at design-time doesn't really seem to work, if one plans to add children objects.

When a datasource is set at design-time, of course an ObjectBinding is created. If I go then to the editor to add an ObjectBinding for a child property, a binding is added which appears to be a copy of the one already there. And, despite setting its TypeName property, the list of columns under the newly-added ObjectBinding remain unchanged, and unchangeable (as nearly as I can determine).

Anyway, this process sets the TypedListName property, as opposed to the TypeName property.

So, I went the route of leaving the VirtualTree.DataSource empty and proceeded to set it up manually.

Once again, using Add (ObjectBinding) doesn't work, for the same reasons detailed above.

I discovered that AutoGenerate seems to work - at first. When I used that, the TypeName property was set, but the tree refused to show any child records.

The generated TypeName property appears to be a fully qualified name, but it is not precisely the same as the syntax one finds in the TypeName ComboBox dropdown list.

Example:
AutoGenerated TypeName: DPMBranchModel.Job - This looks fully qualified to me.

However, until I used the dropdown and chose from the list...
DPMBranchModel.Job, DPMBranchModel

...I didn't get child rows.

That looks like a strange way to qualify a namespace.

I note that the bottom level "child" ObjectBinding doesn't care which syntax is used. It only become important when one wished the ObjectBinding to host child rows.

I may be going about this all wrong. It wouldn't be the first time. I believe that the Winforms paradigm invites, and developers expect, that design-time configuration of user controls should be intuitive and unambiguous. Even if the behavior I detailed above proves to be by design, the VirtualTree still holds great promise for me. I have as yet not found another which gets this close to fitting my needs. I've evaluated more of these things than I care to remember.

I confess to not having fully read the docs. I'll print the relevant sections and spend some time with them later.

Thanks very much.

[Infralution]

For Virtual Tree to be able to resolve types at design time it needs a fully qualified type name. This includes the assembly name ie MyNamespace.MyType, MyAssembly. Selecting the type from the dropdown list is the best way of ensuring that the type will be resolvable. If you specify a TypeName that VirtualTree can't resolve to a type then Virtual Tree will still use the binding at runtime by matching on the type name if possible.

Design time binding and auto-generation of columns and row bindings works reasonable well for DataSets as a means of getting you started quickly when you are dealing with large number of columns. You still will generally need to tweak the generated bindings and columns to get exactly what you want. I probably would not choose to use auto generation for anything other generating an initial set of bindings for DataSets.
_________________
Infralution Support

[EntityDev]

Ok, thanks for the explanation regarding the assembly name.