Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

November 10, 2014, 1:36 pm

≫ Next: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

≪ Previous: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

$

0

0

Hi Christoph,

Did you set the ToolWindowSingleTabLayoutBehavior property as we described above?  When we use this XAML with Coded UI Test, we are able to access all the TextBox controls:

<docking:DockSite ToolWindowsSingleTabLayoutBehavior="Show"><docking:SplitContainer><docking:ToolWindowContainer AutomationProperties.AutomationId="LeftToolWindowContainer"><docking:ToolWindow x:Name="leftToolWindow1" Title="Left 1"><TextBox x:Name="leftTextBox1" /></docking:ToolWindow><docking:ToolWindow x:Name="leftToolWindow2" Title="Left 2"><TextBox x:Name="leftTextBox2" /></docking:ToolWindow></docking:ToolWindowContainer><docking:Workspace><docking:TabbedMdiHost><docking:TabbedMdiContainer AutomationProperties.AutomationId="TabbedMdiContainer1"><docking:DocumentWindow x:Name="document1" Title="Document1"><TextBox x:Name="documentTextBox" /></docking:DocumentWindow></docking:TabbedMdiContainer></docking:TabbedMdiHost></docking:Workspace><docking:ToolWindowContainer AutomationProperties.AutomationId="RightToolWindowContainer"><docking:ToolWindow x:Name="rightToolWindow" Title="Right"><TextBox x:Name="rightTextBox" /></docking:ToolWindow></docking:ToolWindowContainer></docking:SplitContainer></docking:DockSite>

As long as your setup is similar, you should be able to find the child controls ok.  Without that ToolWindowSingleTabLayoutBehavior property set, we do alter the UIA Children but Coded UI Test still doesn't seem to find the children if no tabs show.  That's why as a workaround, adding that property setting helps when there is a single tool window in a tool window container.

---

Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

November 12, 2014, 11:35 am

≫ Next: Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

≪ Previous: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

$

0

0

Yes with ToolWindowSingleTabLayoutBehavior property set to "Show" the controls are found by CodedUI test.

But then an unwanted tab is displayed.
Is there a workaround to make the icon and the text invisible.

Another problem occurs when the DockingWindow is moved from the right edge to another location. No child control can be found afterwards. The recording with the Coded UI Test Builder results in a new tree. A new Automation-Id is assigned to the UIToolWindowContainerPane, e.g. "Toolwindow container 9a57037b-99c2-42a9-9c86-add1e4f5f36b".

Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

November 12, 2014, 11:35 am

≫ Next: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

≪ Previous: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

$

0

0

Sorry for reviving this old thread, but I have further issues to work out with this.

I have a partially working implementation of this, using the MVVM model of driving DocumentItemsSource on the DockSite as presented in the samples (also using TabbedMDI).

The problem is that, though I can change the list of document items from VM and have DocumentWindows generated for them, docking an existing tab from a second window (through a linked dock site) back to the first window does not update the binding source of the DocumentItemsSource property. In other words, the direction of updates is one way for the document items.

Is there any way in the existing docking library for me to keep perfectly synchronized the DocumentItemsSource and the actual document window items, across linked dock sites? I've tried numerous things but have reached something of a dead end here.

Feel free to ask for an example project or further explanation, I realize this is a complex issue.

Thanks again,Michael

Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

November 13, 2014, 9:53 am

≫ Next: Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

≪ Previous: Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

$

0

0

Hi Christoph,

Sorry but you would need that tab visible for the Coded UI Test to run properly if there is no second attached tool window.  Perhaps you can flag it on only when you need to run tests.

If you change the layout then yes, new ToolWindowContainers may be created and others destroyed.  That will alter your visual tree and probably break Coded UI Tests.  I would not recommend changing the layout during a Coded UI Test for that reason.

Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

November 13, 2014, 9:53 am

≫ Next: Removing the outline borders around the tabbed MDI and tool window containers

≪ Previous: Re: ToolWindow prevents visibility of child components by Microsoft Coded UI Test

$

0

0

Hi Michael,

The DocumentsItemsSource is intended to only manage document windows in the same DockSite and not really across linked DockSites.  So unfortunately I think you are trying to do some advanced implementations here that aren't really supported.

All that being said, we have started on prototyping out possible internal redesigns for the future of the Docking/MDI product.  Per a recent blog post, we're currently looking for suggestions on improvements you'd like to see in the product since now is the time to get them in.  Adding the ability to support tear off MDI areas (when documents are floated) is something on our list of goals to achieve.  If there's anything else you'd like to see, feel free to contact us here or at our support address and we can discuss.

Removing the outline borders around the tabbed MDI and tool window containers

November 25, 2014, 1:13 pm

≫ Next: Re: Removing the outline borders around the tabbed MDI and tool window containers

≪ Previous: Re: Programmatically Wrap Floated DocumentWindow in new Window (à la Chrome)

$

0

0

Hi, I am now upgrading out product from 2013.2 to 2014.2. We use the Metro Light theme. I have noticed that the theme has now been updated with 'outline borders around the tabbed MDI and tool window containers'. We need to remove these borders because the design of our application uses inner file with the actual background of the window providing the boundaries or shape of the toolwindow. Can you let me know if it is possible to remove these and if so can you point me in the right direction. Thanks.

Re: Removing the outline borders around the tabbed MDI and tool window containers

November 25, 2014, 1:13 pm

≫ Next: How to stop switching to another tab and keeping it stay at the original tab?

≪ Previous: Removing the outline borders around the tabbed MDI and tool window containers

$

0

0

Hello,

It looks like your company has WPF Studio so I would recommend that you download the default styles/templates for each of the two versions and run the XAML files for Docking/MDI through a diff app.  That will show you the exact changes that were made, such as in Docking's Containers.xaml.  There were also a number of Metro theme resource changes so be sure to diff the XAML files in the Themes.Metro project's folder.  Note that any of the changes there, you can easily revert by including overrides for the resource keys in your App's Resources.  Our Themes QuickStarts show how to do that.

How to stop switching to another tab and keeping it stay at the original tab?

November 25, 2014, 1:13 pm

≫ Next: Do not allow rafted windows to dock to each other

≪ Previous: Re: Removing the outline borders around the tabbed MDI and tool window containers

$

0

0

Here is my case, I'm developing application with MVVM pattern.  I have several "docking:DocumentWindow"s  within "docking:TabbedMdiContainer" control. And I bind the property "SelectedIndex" to property "TabChanged"  in my view model. Here is the case, currenly the tab1 is selected, user input something in this tab and then switch to another tab: tab2.  This action will trigger the set method of property "TabChanged" to take some error check for the content user inputs in tab1, if the check result is false, I want to keep the tab1 selected instead of switching to tab2.  But I cannot make it. Whatever I did cannot stop it from switching to tab2.  Is there any way to make it? Any help will do me a big favor, thanks a lot.

---

Do not allow rafted windows to dock to each other

November 25, 2014, 1:13 pm

≫ Next: Re: How to stop switching to another tab and keeping it stay at the original tab?

≪ Previous: How to stop switching to another tab and keeping it stay at the original tab?

$

0

0

Hi I have a docksite containing several toolwindows. I allow the user to reposition the toolwindows through drag/drop as normal

I have now set the option so that the toolwindows can be rafted/floating.

This allows me to double click the toolwindow to toggle between floating and then docked back in the original dashboard position. However what I want to stop is being able to dock floating toolwindows together but still allow me to dock back in the original docksite.

Is this possible as a setting?

Thanks

Re: How to stop switching to another tab and keeping it stay at the original tab?

November 25, 2014, 1:13 pm

≫ Next: Re: Do not allow rafted windows to dock to each other

≪ Previous: Do not allow rafted windows to dock to each other

$

0

0

Hi Yaron,

Sorry but we don't really have a way to prevent tab changes.  What you could do is call DocumentWindow.Activate(true) when you detect that scenario.  The Activate() method will ensure the document is selected and its content focused.

Re: Do not allow rafted windows to dock to each other

November 25, 2014, 1:13 pm

≫ Next: Removing Close button from RaftingWindow

≪ Previous: Re: How to stop switching to another tab and keeping it stay at the original tab?

$

0

0

Hi Bret,

There are settings for whether a tool window can "attach" (become tabbed) to another tool window.  However please note that that setting will be global and also prevent you from attaching in the docked state as well.

Removing Close button from RaftingWindow

December 2, 2014, 12:31 am

≫ Next: Re: Removing Close button from RaftingWindow

≪ Previous: Re: Do not allow rafted windows to dock to each other

$

0

0

Hi, i currently allow the user to float windows and dock these together. What I would like to do is to remove the close button next to the minimise/maximise button for the rafting window that contains the current toolwindows (I have close buttons already in the header for each toolwindow so that the use has to deliberately close down each toolwindow).

Is this possible programatically or do I have to amend the raftingwindow definition?

Thanks.

Re: Removing Close button from RaftingWindow

December 2, 2014, 12:31 am

≫ Next: Layout serialization and default positions

≪ Previous: Removing Close button from RaftingWindow

$

0

0

Hi Bret,

For that, I don't believe there's a way to programmatically remove the close button.  You'd need to clone and retemplate the RaftingWindow control's template to achieve that.  It nests a WindowControl inside of the template that you would want to set HasCloseButton = false on.

Layout serialization and default positions

December 2, 2014, 12:31 am

≫ Next: Re: Layout serialization and default positions

≪ Previous: Re: Removing Close button from RaftingWindow

$

0

0

I am using layout serialization with ToolWindowDeserializationBehavior = LazyLoad. How do I specify a default window docking position that is only used if the window does not have serialized layout data?

Re: Layout serialization and default positions

December 2, 2014, 1:07 pm

≫ Next: "Close All But This" item in "Active Files" menu

≪ Previous: Layout serialization and default positions

$

0

0

Hi Thomas,

I don't think there is a way to know if a tool window had layout data in the XML other than if you search in the layout XML for a tool window element with the name of your tool window.  If you do that, then following a layout load, you could scan through the DockSite.ToolWindows collection and for any that have IsOpen = false and didn't have layout data in the XML, programmatically dock them somewhere in the layout.

---

"Close All But This" item in "Active Files" menu

December 5, 2014, 10:08 am

≫ Next: Re: "Close All But This" item in "Active Files" menu

≪ Previous: Re: Layout serialization and default positions

$

0

0

Hi,

If you dock multiple documents in a tabbed document container, a glyph appears with the tooltip "Active Files".
Underneath is a context menu with the titles of the files.
When the container is resized, so that not all tabs fit inside, then when you click the glyph, an extra menu item appears in this context menu: "Close All But This"
This item does not belong here. I hope this can be fixed.

Note: the menut item appears most of the times, but not allways.

( I have a screenshot, but i'm affraid I can't attach it anywhere )

 

Regards,

Aernout van Groen

Re: "Close All But This" item in "Active Files" menu

December 5, 2014, 10:08 am

≫ Next: Changing DocumentWindow style: Application cannot run

≪ Previous: "Close All But This" item in "Active Files" menu

$

0

0

Hello,

I don't believe we add that menu option.  It's likely you are adding it in a DockSite.WindowContextMenu event handler.  Note that if e.ContextMenuType == DockingContextMenuType.TabbedMdiContainerOverflowButton, then you wouldn't want to programmatically add that option.

Changing DocumentWindow style: Application cannot run

December 12, 2014, 2:44 pm

≫ Next: Re: Changing DocumentWindow style: Application cannot run

≪ Previous: Re: "Close All But This" item in "Active Files" menu

$

0

0

This question almost answered mine: http://www.actiprosoftware.com-www.actiprosoftware.com/community/thread/20330/changing-floating-documentwindow-style

This is what I want to do (although unfortunately I have no idea how to activate the code-highlighter):

<Style TargetType="{x:Type docking:DocumentWindow}"><Style.Triggers><Trigger Property="IsMouseOver" Value="True"><Setter Property="TabBackground" Value="#038BE4" /></Trigger></Style.Triggers></Style>

That gives me a runtime exception at the first line of my XAML, saying "Cannot have nested BeginInit calls on the same instance." I think this is thrown by System.Collections.ListDictionaryInternal.

Second and subsequent runs of the same code points to my opening Window.Resources tag, and says "Item has already been added. Key in dictionary: 'ActiproSoftware.Windows.Controls.Docking.DocumentWindow' Key being added: 'ActiproSoftware.Windows.Controls.Docking.DocumentWindow'." That's somehow related to both System.Collections.ListDictionaryInternal and System.Windows.ResourceDictionary.DeferrableContent.

Changing the code by so much as removing and adding the same tab character sends me back to the first error.

I reduced my code to this for testing purposes:

<Style TargetType="{x:Type docking:DocumentWindow}"><Setter Property="TabBackground" Value="#038BE4" /></Style> 

That shows what I want to achieve in the designer but otherwise has exactly the same results.

What am I doing wrong? What is BeginInit and how is it relevant? And, for curiosity's sake, why am I apparently adding key-value pairs to a persistent dictionary?

Re: Changing DocumentWindow style: Application cannot run

December 12, 2014, 2:44 pm

≫ Next: DocumentWindow tab hover color, except not activated by the window itself

≪ Previous: Changing DocumentWindow style: Application cannot run

$

0

0

Apologies, I had a previous <Style TargetType="{x:Type docking:DocumentWindow}"> in the same Window.Resources element. Never mind!

DocumentWindow tab hover color, except not activated by the window itself

December 12, 2014, 2:44 pm

≫ Next: Re: DocumentWindow tab hover color, except not activated by the window itself

≪ Previous: Re: Changing DocumentWindow style: Application cannot run

$

0

0

Context: http://www.actiprosoftware.com-www.actiprosoftware.com/community/thread/22907/changing-documentwindow-style-application-can

Now that I have that working, the tab hover color is changing properly, but it's also changing when I hover over the window content. The default hover color is not subject to this behavior; what's different and how can I eliminate the undesired behavior?