Scrolling to Selected row

[tom_cole3]

I have a table which is displaying a tree structure via a MasterColumn. This tree view represents the Org Structure for a company.

As this tree can be pretty large, I wanted to provide a search box in the Table's toolbar where it will find the first / next org unit that matches the search string and select it. This I have written successfully. It also automatically expands the tree as needed so the item is displayed before being selected.

My problem is although it selects the row properly, it does not make the selected row visible. The user still has to hit the page down arrow in the footer to find the selected row. This is not desirable. At first I thought I could bind the firstVisibleRow attribute to a context element, but this is a tree structure. How would I know which "row" the recursive element is occupying? This would potentially be a rather complicated calculation to need to perform.

Is there some setting/way to make the selected row automatically become the firstVisibleRow? Or is there some easier method to determine which row in the table (and not which element in the node) is selected?

Many thanks.

[tom_cole3 · Accepted solution]

I have gone ahead and created a recursive method that accurately calculates the visible row number of a selected element in my recursion node.

Now I have created a context attribute that is calculated and reference that recursive method to return the int of the selected visible row. I have bound the FirstVisibleRow attribute of my table to that value. This does indeed calculate the row and make it the first visible row.

Now my new problem is that I can't navigate up or down as this value is always calculated unless I search for another value. But the up and down buttons on the footer don't respond.

So I have setup a boolean that indicates if the first visible row should be calculated or not. My question is this, how can I remove a binding dynamically in the wdDoModify? I see how to bind dynamically but I cannot see how to remove the binding for when the first visible row should NOT be calculated.

Thanks in advance.

[tom_cole3 · Accepted solution]

So I have figured that I will create a second context attribute that is not calculated, and then I can switch the binding from the calculated to the non-calculated attribute as necessary. Of coures this must happen in the wdDoModifyView method.

So now to my next problem. Apparently clicking the up/down arrows in the table footer does not fire an action, at least not one that causes a wdDoModifyView to get called. So my code to switch the binding does nto get hit, unless I click on something else that has an action assigned to it.

Getting closer but still far from acceptable. IAny ideas on how to make the clicking of the up/down row/page buttons generate an action that will cause wdDoModifyView to get called?

[siarhei_pisarenka3 · Accepted solution]

Hi Tom

Why do you need the calculated attribute? Update the table's firstVisibleRow property only when you perform the filtering and row selection.

I think you do not need to bind the table's property to the context. Instead of this, when you perform the row selection get an instance of the table and set the property:

IWDTable table;
...
table.setFirstVisibleRow(row);

BR, Sergei

[Former Member · Accepted solution]

Don't use a calculated attribute here, use a normal one. Bind "firstVisibleRow" to this attribute and just set the attribute value whenever you want to scroll the table to the selected row. Then scrolling through the table will just overwrite the attribute value and keep it in synch with the table's state.

Armin

[Former Member · Accepted solution]

Hi,

I'd use either what Armin suggested or a different approach, which would be "moving" the Node pointer to your desired row. Calculated attributes are only being "Calculated" when the Node which it's in get's dirty and then, refreshed. So you need to use them carefully. I use them whenever I can, since I dont like the way we control some screen elements in WDP, which in my opinion, is not good at all.

Using the Move option, it will point your Table as "lastVisibleRow", this method is avaiable under IWDNode interface.

Regards,

Daniel

[tom_cole3 · Accepted solution]

Yes, that was my eventual solution. I moved the logic that I was using in the calculated getter and moved it to inside the search action. Then made the attribute non-calculated and it worked just fine.

Thanks.

[Former Member · Accepted solution]

"I dont like the way we control some screen elements in WDP, which in my opinion, is not good at all."

Can you give some example?

Armin