Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MasterDetailsView stays in the Master ViewState after resizing #906

Closed
JulienTheron opened this issue Feb 9, 2017 · 26 comments
Closed

MasterDetailsView stays in the Master ViewState after resizing #906

JulienTheron opened this issue Feb 9, 2017 · 26 comments
Assignees
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior controls 🎛️
Milestone

Comments

@JulienTheron
Copy link

JulienTheron commented Feb 9, 2017

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.

@skendrot
Copy link
Contributor

skendrot commented Feb 9, 2017

Can you provide a repo? This is not reproducible with the sample app

@JulienTheron
Copy link
Author

JulienTheron commented Feb 9, 2017

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.

@skendrot
Copy link
Contributor

skendrot commented Feb 9, 2017

Thanks @JulienTheron. I'll look into it

@deltakosh deltakosh added bug 🐛 An unexpected issue that highlights incorrect behavior controls 🎛️ labels Feb 9, 2017
@deltakosh deltakosh added this to the v1.4 milestone Feb 9, 2017
@skendrot skendrot self-assigned this Feb 9, 2017
@yanxiaodi
Copy link

I found this problem too. I have writed a statetrigger to resolve it. I'll pull a request about this.

@skendrot
Copy link
Contributor

skendrot commented Mar 9, 2017

@JulienTheron or @yanxiaodi can you confirm that the changes above fix this issue for you?

@JulienTheron
Copy link
Author

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.

@yanxiaodi
Copy link

@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.

@skendrot
Copy link
Contributor

@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?

@h82258652
Copy link
Contributor

@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.

@skendrot
Copy link
Contributor

@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();
    }
}

@yanxiaodi
Copy link

yanxiaodi commented Mar 13, 2017

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.

@yanxiaodi
Copy link

@h82258652 Good job. Thanks.

@JulienTheron
Copy link
Author

@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.

@skendrot
Copy link
Contributor

@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.

@skendrot
Copy link
Contributor

@h82258652 while the control is "simpler" the overall implementation is much more complex.

@h82258652
Copy link
Contributor

@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? 😁

@skendrot
Copy link
Contributor

@h82258652 Please log a new issue and let's keep this thread to the issue that @JulienTheron submitted

@skendrot
Copy link
Contributor

skendrot commented Mar 13, 2017

@JulienTheron Yes, without debugging I cannot reproduce. I cannot reproduce with the UWP Toolkit sample app or in a new standalone app.

@JulienTheron
Copy link
Author

@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.

@skendrot
Copy link
Contributor

@JulienTheron I did not download your repo, just copied the xaml and code behind to a new project I created

@yanxiaodi
Copy link

@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!

@skendrot
Copy link
Contributor

skendrot commented Mar 14, 2017

Thanks. And that issue was addressed in #891, correct?

@yanxiaodi
Copy link

@skendrot Yes. Thanks a lot!

@deltakosh
Copy link
Contributor

So we can close this issue?

@JulienTheron
Copy link
Author

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.

@skendrot
Copy link
Contributor

Unless someone else can reproduce the issue, I do not see a need to keep this open

@ghost ghost locked as resolved and limited conversation to collaborators Nov 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior controls 🎛️
Projects
None yet
Development

No branches or pull requests

5 participants