DynamicDataManager and SelectedIndex

Question

User645151313 posted

Does the DynamicDataManager cause the first item in a GridView or ListView (for example) to get selected when the control is data bound? I am trying to develop my own generic page template but as soon as I register my control with the DynamicDataManager the SelectedIndex is set to zero after the control data binds. This is not the behaviour I need and I cannot find a way to disable it.

Answer 1

User660823006 posted

Yes, it does do this and it was so in the case of a master/detail the master has a selected row so the detail doesn't try and grab all the values. All of the work that DynamicDataManager does is done in the Page_Init events I think so you should be able to override this in Page_Load: if (!IsPostBack) { GridView.SelectedIndex = xxxx }

Answer 2

User645151313 posted

Scott,

Unforunately this doesn't work - the selected index seems to get set back around the PreRender phase, probably when the data binding occurs. I have tried setting both GridView1.SelectedIndex = -1 and GridView1.SelectedPersistedDataKey = null. It is a shame the DynamicDataManger has this behaviour baked in as it is needed for other Dynamic Data functionality. Is it possible to add the ability to disable certain behaviours like this, e.g. by a property on the control itself, in the next release?

  

Answer 3

User660823006 posted

We are looking into this and I'll post a fix if we can come up with one.

Answer 4

User1641955678 posted

Hi Matt,

Can you try something like this: 

        DynamicDataManager1.RegisterControl(GridView1, true /*setSelectionFromUrl*/);

        GridView1.PreRender += delegate(object s, EventArgs eventArgs) {
            GridView1.SelectedIndex = -1;
        };

  

David

Answer 5

User645151313 posted

David,

So I'm working with the Dynamic Data v1 ListDetails.aspx page template and I've added this code:

    protected void Page_Init(object sender, EventArgs e) {
        DynamicDataManager1.RegisterControl(GridView1, true /*setSelectionFromUrl*/);
        DynamicDataManager1.RegisterControl(DetailsView1);

        if (!IsPostBack)
        {
            GridView1.PreRender += delegate(object s, EventArgs a)
            {
                GridView1.SelectedIndex = -1;
            };
        }
    } 

Note I still want to have row selections to support the master-detail functionality. I just don't want a selection on page-load, hence the IsPostBack check. This variation on your suggestion seems to work on the surface but not in all cases.

1. It probably breaks the 'setSelectionFromUrl' feature.
2. When inserting a new row the DynamicDataManager forces the selection on me again. I'll probably need to handle the DetailsView.ItemInserted event and attach your GridView.PreRender delegate again.
3. In addition I'll have to now hide the DetailsView initially on page load (or display in InsertMode) as it still binds to the first row.

It is good to hear that the DynamicDataManager behaviour might become more flexible / configurable. It bothers me that there is work going on behind the scenes that I am simply undoing. 

 

 

Answer 6

User1641955678 posted

Hi Matt,

Just to make sure I fully understand the behavior you're trying to achieve: when you first navigate to the ListDetails page, you don't want the GridView to show a selection.  But what do you want the DetailsView to behave?

1. The first item, and have its data source only bound to the first item.
2. The first item, and have its datasource bound to all items (set AllowPaging=true on the DetailsView to see the distinction).  Doing this is bad, as it's super inefficient and generates huge view state.  That's mostly what drove us to auto-select the first item.
3. Hide the DetailsView altogether.  The problem with that is that you then lose the ability to add a new item until you select something in the GridView, which is quirky.

Note that I certainly agree with you that having to undo some of the Manager's behavior is unfortunate, and we'll try to address this.

David

Answer 7

User645151313 posted

David,

Thank you for spending time on this. I think the feedback developers get on these forums from Microsoft employees is great - particularly on this forum.

The page template I am aiming for is one that my team and I have hand-crafted on a number of projects now, using a ListView and FormView. I am trying to create a templated version using Dynamic Data to reduce repetitive coding effort on the next project.

It is hard to describe the UI without pictures but I'll have a go.

On the first page load I do not want to force a selection from the master list. I accept your point that raises the question of what to do with the detail view. We hide it by default and this also stops it from trying to auto-bind all records.

At this point the user has two options. (1) Click a page-level [Add New] button, which is wired up to an event handler that puts the detail view into insert mode and makes it visible. (2) Select a row from the list, which puts the detail view into edit mode and makes it visible. Both of these actions basically work on a toggle basis to show/hide the detail view in the correct mode.

The user can then either press [Cancel], which basically just reloads the page. Alternatively the user can press [Save], which will detect the current visibility and mode of the detail view and call the appropriate InsertItem(...) or UpdateItem(...) method. Both of these buttons are again at the page level and are not command buttons within the master/detail controls.

The final option in edit mode the detail view displays a [Delete] button somewhere within the edit item template. This is the only command button used and we choose to put it here but it could easily be relocated to each row in the master list if we choose.

<Table Name> - [Add New]
------------------------
Row 1          [Select]
Selected Row 2 [Select]
Row 3          [Select]

<Table Name> Details
-----------------------
Field 1        [Delete]
Field 2
Field 3

[Save] [Cancel]

By replacing the master/detail control command buttons with page-level buttons we are taking on more work for ourselves but it gives us greater control over the UI. Just one minor example of this is the ability to place these buttons anywhere on the page. The added work will essentially be mitigated if I can work this into a generic Dynamic Data page template.

I hope that explanation is clear enough. If in the next version of Dynamic Data the ListView double-bind bug is fixed, the DynamicDataManager auto-select behaviour is configurable and the entity templates are available then I'm absolutely positive I can template all of the functionality we have in our custom hand-crafted standard pages. In the meantime I will probably get all of this implemented with workarounds and custom template code respectively.

Answer 8

User1641955678 posted

Hi Matt,

Sorry for the slow response.  I think I generally understand the kind of pages you're building.  Here is a somewhat smarter version of the workaround above:

            if (!IsPostBack && GridView1.SelectedPersistedDataKey == null) {
                GridView1.PreRender += delegate(object s, EventArgs eventArgs) {
                    GridView1.SelectedIndex = -1;
                };
            }

The extra check takes care of the case when the selection comes from the URL.  Note that there is a subtle connection between the concept of the SelectedItem (which is always on the current page), and the SelectedPersistedDataKey (which may be an item not currently in view).

Another issue you had mentioned above was "When inserting a new row the DynamicDataManager forces the selection on me again", and I don't really see this.  In theory, when inserting a new item, the selection is kept to whatever it was before (basically, the insert doesn't affect the selection).

thanks,
David

Answer 9

User645151313 posted

David,

I've implemented your suggestion. Regarding your final point:

"Another issue you had mentioned above was "When inserting a new row the DynamicDataManager forces the selection on me again", and I don't really see this.  In theory, when inserting a new item, the selection is kept to whatever it was before (basically, the insert doesn't affect the selection)."

I think a simpler way to repro this is to click on a column header to cause the list to be sorted. You should notice the row that _would_ have been selected by the DynamicDataManager gets selected when the list is bound after the sort. A list with two or three rows (single page) and a selected row style is best for identifying this behaviour. Do you think it is better for me to wait until a release when the DynamicDataManager is more configurable, rather than trying to fight its current behaviour like this?

Thanks,
Matt

Answer 10

User1641955678 posted

Hi Matt,

I still think we can find a good workaround for you that will handle all cases.  Here is the next attempt, which works correctly in the Sort cases you found:

 

        protected void Page_Load(object sender, EventArgs e) {
            // ...
            // Unrelated things deleted.  Just add this one line at the end
            LoadComplete += new EventHandler(ListDetails_LoadComplete);
        }

        void ListDetails_LoadComplete(object sender, EventArgs e) {
            if (GridView1.SelectedPersistedDataKey == null) {
                GridView1.PreRender += delegate(object s, EventArgs eventArgs) {
                    GridView1.SelectedIndex = -1;
                    GridView1.SelectedPersistedDataKey = null;
                };
            }
        }

Let me know how that works! :)
David