How to remove header and all actions from SlideGroup of WindowsUIView?

I'm afraid that ticket you posted does not contains any viable solution to my problem with Back button. SlideGroup is self contained control with two "views" - one is scrollable view with all documents lined horizontally and second is zoomed view (like Page) of the document. Back button is displayed on zoomed document view and I didn't found any way to hide it.
Ideally I want not only hide Back button but also hide document name from the caption and reduce remaining empty space so only document control is visible (so there should be no space between control that placed above WindowsUIView and document control).

Hello,

To accomplish this task, handle the WindowsUIView.ContentContainerHeaderClick  event and set the e.Handled property to true.  This will prevent the default navigation.

Then, you can show the required control in any way you require. I've attached a small sample project illustrating the main idea. If you have a complex navigation in your application, you can create a new instance of your control and show it, for example, in another container so it occupies all the available space.

Let me know if you have additional questions.

Here, I prepared screenshot illustrating what I want to do. In upper part of screenshot is displayed zoomed SlideGroup document, as you can see document caption is visible and cover much of the view space. In the lower part of screenshot is what I want to do - hide zoomed document caption so only document control is visible. This way document caption is not cover any view space.
Hope it make sense now.

Hello,
As I can see in your screenshot, you are using the PageGroup container. If so, you need to hide document captions, the back button and document buttons, and then set the content margins for the corresponding skin element to 0. I've attached a sample project illustrating this approach. Does this solution help?

No, as I said I'm using SlideGroup and I want remove header on ZOOMED document. It is NOT PageGroup.

Thank you for the clarification. In this case, it is a complicated task to remove the Back button and the space that it takes. I suggest you use the same approach I described above and in addition, handle the WindowsUIView.CustomDrawBackButton event:

C#
private void windowsUIView1_CustomDrawBackButton(object sender, CustomDrawBackButtonEventArgs e) {  
    e.Handled = true;  
}  

In this case, there will be some empty space at the top of the document. Does this result meet your requirements?

In this case document header/caption remains and I want to remove it completely.

Hello,
In this case, I suggest you create a SlideGroup descendant and use Page as a container for zoomed documents. I've attached a modified sample illustrating this approach. Please review it and let me know if this solution is suitable for your scenario.

Thank you!

And a suggestion - maybe you should make DocumentContainer class used in SlideGroup public? It will be great.

I mean DetailContainer, sorry.

Hello,
At the moment, we don't have such plans. In any case, even if this class was available, you would need to set DetailContainer's Parent to null, and this setting may produce exceptions. So, it is better to use Page in this scenario.
Please feel free to contact us if you have further questions.

Actually, it is enough to set HeaderOffset to -92 to completely hide header of both Page and DetailContainer without bothering to disable default Back button and hiding header.

Hello,
Yes, this solution works in a common case, however, it may produce side effects in the future since value 92 is hardcoded in this case. If this approach is more convenient for you, you can test it thoroughly and proceed with it if there are no issues.
Please do not hesitate to contact us in case of further difficulties.

Yes - its hardcoded value. If there any way to measure content container header height then I would prefer to use this way to calculate appropriate header offset. Is there anything that can help me with this task?

Hello,
Methods that calculate the container header height are not in the public API, so you need to create several descendants and override several methods to access them. Would you please clarify if the approach suggested above (using a Page as DetailContainer) meets your requirements? If not, explain why. In this case, we'll prepare an example illustrating how to adapt the second approach (your suggestion).
I'm looking forward to your response.

Currently im using mix of your suggestion (Page container) and my workaround with hardcoded HeaderOffset. Im still testing all cese scenarios but it seems this approach is working just fine. If content containers headers will not be changed in the future then this approach is suitable for me.

It is not quite clear why you have to use the workaround you found together with my approach. Doesn't my solution (with the Page container) work correctly without setting the offset? If there are any issues, please modify my sample to illustrate them. We'll do our best to find a more precise solution.

I need Back button to switch to SlideGroup documents view. Not really Back button but Page.Paresn set to SlideGroup so I can distinguish SlideGroup document container (which have their Parent set to SlideGroup) from any other. I need it to correctly display containers from my framework.
As far as I know there is no way to remove Back button in this case, besides, I need to set Page Caption so this container will appear in Search results of SearchPanel so there is no way (as I see it) not to use HeaderOffset.
Maybe I will create small demo demonstrating what I mean.

Here, I created crude sample for demonstration purposes.
User can switch to documents view via Test menu Documents tile - user switched directly to document. If user want to switch to another document he must use Documents subitem. For demonstration purpose only Overview subitem is created - this item switches user to SlideGroup main view (with documents lined up horizontally). From here user can switch to any document he wants.
Of course its not all functionality but the core of it. I need Parent properties set correctly for all ContentContainers to correctly switch between them in my framework. Please, review this sample and if you have any suggestions I would be very pleased to hear it. Thank you!

In your scenario, this approach appears to work correctly. Nevertheless, I still can't see why you need the Parent property to be set for detail containers. I see that all document navigation is implemented manually. Please clarify what stops working if you set the Page.Parent property to null.

I said - this sample is the demo. Actually all my navigation is handled by framework of my own and for correct navigation I need Parent property to be initialized correctly.
For example, when user switch from Files to Documents, he navigates (via my framework) to last opened document, but when he clicks on Overview SubItem he must be navigated to SlideGroup main view without closing the document (I must close the document if user does not made any modifications and navigated to different content container). To check if user navigated to SlideGroup from one of its container (documents) I need to check its Parent - if this parent is another content container and SlideGroup is not its parent I must navigate to last opened document otherwise I need to let SlideGroup to open its main view.
Its somewhat complicated without example but I cannot provide you with one.

Hi,

Olga is out of the office today. She will be more than happy to continue assisting you with this issue tomorrow. I appreciate your patience.

Hello,
Thank you for the clarification. Now I better understand your scenario.
I researched our source code and found a way to obtain the required header offset dynamically. Handle the WindowsUIView.ContentContainerActivated event as follows:

C#
private void windowsUIView1_ContentContainerActivated(object sender, ContentContainerEventArgs e) {  
    IContentContainerInfo info = e.ContentContainer.Info;  
    BeginInvoke(new Action(() => e.ContentContainer.Properties.HeaderOffset = -info.Content.Top));  
}  

Please test this approach and let me know if it helps.

Thank you!

It certainly better solution but flickering is killing it all.

Hello,
I wasn't able to reproduce this flickering effect with your sample. Should I add more controls to documents to see it in action?
BTW, we discussed this functionality with our developers and there is the possibility that we'll implement it out of the box in one of the future releases. I've created a ticket on this subject on your behalf (WIndowsUIView - Provide the capability to hide a caption for a particular content container).

Flickering only visible when document is displayed for the first time for a split second and is not so obvious when I implement your solution in my test project, but when I tried to implement it in my real-life application the flickering of the header became noticeable.
It is great if hiding content container header will be implemented in one of the future releases! I will wait. For now I stick with my hardcoded HeaderOffsets.
Thank you!

Here - I tried to reproduce flickering in my test project, but as I said - its not as severe as it was in my real-life project.
Just switch to Documents via Test Menu -> Documents and then press nav button on the left from menu several times to create some new documents - some flickering will be visible since ribbon control paints twice - one time with content container header height in mind and second time without content container header.