Stop a button on Tab from closing it

And I realize this is not on the latest version, but upgrades are currently not permitted at my company.

Hi Lutz,

Yes in the older pre-2016.1 Docking/MDI API, the TabbedMdiHost.IsCloseButtonOnTab property could be set to false to hide that close button.  I believe it used an inherited attached property to pass the value you set on that TabbedMdiHost property down to the docking window instances.

I'm not sure what XAML you are using to set up the tabbed UI but generally if you are using our document windows, you have a structure somewhere in the app like DockSite / Workspace / TabbedMdiHost.  That is where you'd set the property.

Thanks for the reply. Just to clarify, I'm not trying to hide any buttons. That property is causing an unrelated button that changes the sort order on something we display to close the flyout. There's no regular close button.

The XAML is really simple. It applies a ControlTemplate (to a custom control derived from Control) like this:

<DockPanel>
   <Grid />
   <Grid>
     <TabControl> 
        <TabItem />
        <TabItem />
        <TabItem />
     </TabControl/>
   <Grid>
</DockPanel> 

One of the TabItems has a DockPanel in it and that DockPanel has a ToggleButton in it. Clicking that toggle button closes the flyout. Interacting with other controls (like combo boxes or listviews) on the tabs does not cause a close.

There is no ActiPro-specific XAML. Programmatically looking for TabbedMdiHost in the ancestors and descendants of the control also did not turn up anything....

- Lutz

Hi Lutz,

Ahh, I think I understand better now.  It is perhaps the TabbedMdiHost.IsCloseButtonOnTab attached property that inherits down into your flyout based on an ancestor TabbedMdiHost in the flyout anchor control's visual hierarchy (like you use a TabbedMdiHost in the main window that contains the flyout anchor control)?

And you are saying if you set the attached property on your flyout to be false, the flyout doesn't close when your other button on the flyout is clicked?

Offhand, I'm really not sure why that attached property would make any difference for how buttons on the flyout operate.  You could just set it to false on your root flyout element if that workaround fixes it.  Or if you'd like us ot look into it further, please put together a new simple sample project that shows it happening and email that to our support address and we'll debug with it.  Please rename the .zip file extension and exclude all obj/bin folders to ensure it doesn't get spam blocked.

Yes, that is correct. In Snoop, I uncheck that property and the button behaves as expected and does not close the flyout. 

You could just set it to false on your root flyout element if that workaround fixes it.

Yes, that is what I'm trying to do, but can't. :-)  I can't find the attached property in code. And I can't do it in XAML since the upper hierarchy is not in my XAML file.

You guys should look at Telerik's sample app, it is awesome to browse how to use their controls.

I'm having a very hard time getting up to speed on how to structure the XAML in my app. The help file is not helpful a whole lot, there's barely any sample XAML I can see. Maybe I'm missing the samples, I'll take another look. But a end-to-end guide to creating an app with certain features (in my case a MDI app) would be very useful.

You should be able to do it anywhere in your XAML above the button like:

<YourRootPopupElement docking:TabbbedMdiHost.IsCloseButtonOnTab="False">...

Or use the TabbedMdiHost.SetIsCloseButtonOnTab method in code to apply it. 

And in regards to samples, our main sample project that comes with the controls has hundreds of samples in it.  Everything from demos that show many features together to QuickStarts that focus on specific product feature areas.  The documentation is meant to be used in addition to that sample project.

Yeah, I figured that out shortly after my post. Unfortunately, it did not solve the problem reliably. The flyout still closed, even with that flag set to false. I'm beginning to suspect it's something else, maybe focus-related....

Anyway, I was going to try and put together a test app to demonstrate, but am having a hard time with your documentation. And it seems our IT department has not made the samples available and they're not available for download from your site. We don't run installers on every developers machine here.

Fun times.

In general, if you have a WPF Button within a secondary focus scope area (like a ToolBar or Menu or Ribbon), code in Microsoft's native WPF Button will move focus back to the main focus scope portion of your app.  Perhaps that's what you are running into here? 

I really don't think our attached property has any effect on this particular scenario and it's probably happening due to something like the above.

I think you're right. The AutoHideHost seems to never get real focus. Is there a way to influence when the AutoHide triggers?

I was watching the Live Visual Tree in VS15 and tracking the focused element. Focus stays on the control that was active in the main app when I trigger the flyout. No focus changes take place while interacting with controls on the flyout, but when I click that button on the flyout, it closes and focus goes to the topmost app window (the root). Weird.

Hello,

Auto-hidden tool window popups don't automatically gain focus on hover over the tool window tab.  But they should gain focus if you clicked on the tab to show them.  And the controls on the popup should gain focus if you click on them.  The only time that normally isn't the case is if you have a secondary focus scope like toolbar that the button is in.

It's hard to say without having something to debug wtih.  If you'd like us to take a look, please make a new simple sample project that shows it happening and email that to our support address, referencing this thread.  Be sure to exclude any bin/obj folders in the ZIP and rename the .zip file extension so it doesn't get spam blocked.  Then we can debug with that and see what's happening.