Hi,
I've discovered an issue with the MasterDetailsView control.
When the control is displayed on a window whose width is less than 720px, and then I expand the width of the window, the ViewState of the MasterDetailsView doesn't change. The ViewStateChanged event isn't raised, and the BackButton isn't shown (the MasterDetailsView is on the MainPage). If an item is selected in this state, the event is raised, and the BackButton is shown.
Note: This does not happen when a debugger is attached.
Thanks.
Can you provide a repo? This is not reproducible with the sample app
Hi just created a repo to reproduce the issue.
I subscribed to the ViewStateChanged event in order to auto-select the first item when the ViewState is Both.
Make sure not to be attached with a debugger when launching the app.
MasterDetailsView_Issue906
Thanks.
Thanks @JulienTheron. I'll look into it
I found this problem too. I have writed a statetrigger to resolve it. I'll pull a request about this.
@JulienTheron or @yanxiaodi can you confirm that the changes above fix this issue for you?
Hi,
Still not fixed with the 1.4.0-dev00138 package.
I think the issue may come from the fact that there is a mismatch between the content of the VisualStateChangedEventArgs and stateGroup.CurrentState. Did you try passing VisualStateChangedEventArgs.NewState to the UpdateViewState method?
Thanks.
@skendrot I didn't use this control to implement my purpose. Because I need to control the state by the content of the detail panel, not only depends on the width of the window. When the content of the detail area is empty or not empty, the control's performance should be different. So I write a new state trigger to finish it.
@yanxiaodi Can you give more details? What do you mean by "the controls performance should be different"? Does the ViewState property not meet your needs for controlling which state the control is in?
@yanxiaodi How about this? https://github.com/h82258652/UwpMasterDetailViewSample
I think the MasterDetailView in this toolkit is too much complex. I have to create my own for my apps.
@JulienTheron I still cannot reproduce the issue. I am doing the following:
private void MasterDetailsView_ViewStateChanged(object sender, UI.Controls.MasterDetailsViewState e)
{
if (e == UI.Controls.MasterDetailsViewState.Both)
{
MasterDetails.SelectedItem = Emails.First();
}
}
I mean that:
1.Run the app and resize the window to the wide mode, the detail view is blank now.
2.Now resize the window to the narrow mode, you should see the detail view is hidden. Only the master view is visible.
3.Then resize the window to the wide mode. The detail view will be visible again.
4.When you click a item of the master view, the detail view will show the content. Now resize the window to the narrow mode, the master view will be hidden and only the detail view will show. Then click back button, the detail view will be hidden, and the master view will show.
5.Now resize the window to the wide mode, the detail view shows again.
In different width modes, whether to display the Master view or the Detail view depends not only on the window width, but also on whether the Detail view is Blank.
So I need another parameter to indicate whether the Detail area is Blank. Only the windows width is not enough.
A good sample of the Master/Detail View is Mail App.
@h82258652 Good job. Thanks.
@skendrot I just rerun the app provided in the MasterDetailsView_Issue906 repo with the latest toolkit package (preview) and the issue is still there. Did you run it without being attached to the debugger?
Here are simple repro steps:
1- Open the app and resize it so that only the Master page is displayed.
2- Close the app.
3- Open the app again. Only the Master page should be displayed.
4- Expand the window width. The first item should be selected (but it's not).
Thanks.
@yanxiaodi I'm very confused. The MasterDetailsPanel works exactly like the Mail app. When there is a narrow width and an item is _selected_, it should show only the details section. When there is a narrow width and no item is selected, it should show the master section. When there is a wide width it should show both sections if something is selected or not. This is dependent on selection of the master section, not about the detail being "Blank"
Your steps above describe exactly how a MasterDetailsView should behave.
@h82258652 while the control is "simpler" the overall implementation is much more complex.
@skendrot Yes, I agree with you. But I don't think the MasterView contains a ListView is a good implement. Maybe I want a PullToRefreshListView? :grin:
@h82258652 Please log a new issue and let's keep this thread to the issue that @JulienTheron submitted
@JulienTheron Yes, without debugging I cannot reproduce. I cannot reproduce with the UWP Toolkit sample app or in a new standalone app.
@skendrot I cannot reproduce it either with the sample app, must have to do with the way the UI is organized. Did you try with the repo I provided? My teammate is able to reproduce it as well.
@JulienTheron I did not download your repo, just copied the xaml and code behind to a new project I created
@skendrot Sorry! I made a mistake. I must apologize to you.
What I have just said is actually the problem about the Master/Detail sample in Template10, not UWPCommunityToolkit. I remember that I have to rewrite a state trigger just because I need to put a pivot control in the master view. But the Master/Detail control has binded a ListView. This is the real reason, not the behavior about the control. I confused these two projects.
Sorry!
Thanks. And that issue was addressed in #891, correct?
@skendrot Yes. Thanks a lot!
So we can close this issue?
Please don't close it.
The issue is there and easy to reproduce (from my experience). I don't understand why @skendrot has trouble to reproduce it.
I can even reproduce it on my Lumia 950 XL.
When the issue happens, it has many undesired side effects, such as going back from the Details view to the previous page (when pressing on the BackButton) instead of going back to the Master view.
Unless someone else can reproduce the issue, I do not see a need to keep this open