cancel
Showing results for 
Search instead for 
Did you mean: 

Binding an IWDTable to a non-singleton IWDNode

Former Member
0 Kudos

Hi all,

can anybody give me an idea on the following topic:

I have a Context that contains Nodes of type A, who have as children nodes of type B, which, in their turn, contain attributes.

B nodes are non-singleton (therefore any element of the type A owns its own node B).

I want to create dynamically a set of tables that are bound to the B-nodes (each table to one B node depending on an A-node).

When trying

for( * each elementA in nodeA) {

...

IWDTable table = ... create new table ...

table.bindDataSource(elementA.nodeB().nodeInfo());

...

}

the only result is a set of tables containing the data in one elementA (this may be because of the LEAD_SELECTION);

The question is: it is possible to do what I described above ? (create a set of tables, each pointing to it's own non-singleton node).

Now, the documentation & practical facts didn't help in any way, since in the documentation it is written that the table binds to the node (and this is also the idea of binding itself), but on the other hand, the bind method receives as parameter the IWDNodeInfo rather than the IWDNode itself. The IWDNodeInfo happens to be the same instance for all the nodes, even if they are non-singleton, therefore how could the table figure out which is the target node for binding ?

Anyone that knows something about that, please advise.

Many thanks,

Marius

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Marius,

I am currently experiencing the same issue you did. How did you finally solve this (or: did you at all)?

Is anybody still in need of or working on a solution/workaround?

Kind regards, Johannes

Former Member
0 Kudos

This is not possible.

Would it be an option to declare a fixed number of singleton B nodes instead? Or could you live with a master-detail view where there is only one detail table displaying the B-elements corresponding to A's lead selection?

What if the number of elements in A is very large? How does your UI look like?

Armin

Former Member
0 Kudos

Thanks Armin,

Instead of a fixed number of nodes I manipulated a number of context nodes programmatically.

If the number of tables/nodes is very large the UI will be ... ugly, at best. But that's not the point, the idea is that the context supports some sort of data organization (namely sets of table-like structures), and the table binding seems to lack the support to making use of it (I don't think that preventing flaky UI's is the best main reason why this is happening). Maybe in the next version.

Best regards,

Marius

Former Member
0 Kudos

> If the number of tables/nodes is very large the UI

> will be ... ugly, at best. But that's not the point,

> the idea is that the context supports some sort of

> data organization (namely sets of table-like

> structures), and the table binding seems to lack the

> support to making use of it (I don't think that

> preventing flaky UI's is the best main reason why

> this is happening). Maybe in the next version.

No, the context structure you described is a tree-like structure, not a table-like structure. So you are on the wrong track here. It's comparable with the Windows explorer, if you click on a folder node on the left side, you'll get a list of files and folders on the right. What you need here is something like a tree table, which is announced to be added soon.

Best regards

Stefan

Former Member
0 Kudos

Hi,

Thanks Stefan for the info you provided.

However, I needed a solution to a different kind of problem than the Windows Explorer-like one you mentioned. Although the table tree control won't solve this particular problem of mine, I'm eager to see it at work. So ... can wait for it ! Does anyone know when is it going to be released ?

Marius