Setting ToolWindow.IsOpen=True not opening the tool window

Hi Justin,

I'm not thinking that you can have the ToolWindow in the XAML and set IsOpen="False" initially.  I don't believe that's a scenario we support.  You could probably load your full window and then set the binding to IsOpen programmatically after it's loaded.  In that case it would likely hide appropriately and work from that point on.

But in general, you shouldn't put a tool window in the XAML if it's not meant to be initially open.  MVVM scenarios will be easier to handle in the 2016.1 version since you'll have properties you can set (even bind to) that tell the window where to go for its default location.  2016.1 should be out very soon.

>>I'm not thinking that you can have the ToolWindow in the XAML and set IsOpen="False" initially. I don't believe that's a scenario we support.

I'm not sure I quite understand why every tool window would need to be open initially to be openable later?  It seems a very common scenario, to launch with an interface where only 'essential' toolboxes are shown, but others can be revealed later via menus or events that necessitate their use.  Visual Studio, for instance, has lots of tool windows it doesn't show initially, but which you can later open i.e. from the View menu?

Or did I misunderstand what's not supported?

>>MVVM scenarios will be easier to handle in the 2016.1 version since you'll have properties you can set (even bind to) that tell the window where to go for its default location.

Hmm - does this mean it'll work properly once that's released?  If so, I can definitely hang tight on releasing this ToolWindow until next week :)

Hi Justin,

Well the scenario of having a tool window in XAML that isn't meant to initially be there isn't something we support.  You should only have tool windows in XAML that are meant to be open at app startup, or as a default.

In the 2016.1 version, you are able to set various properties (directly or via bindings) that let you say you want the tool window to default it's location on a certain side, or with a certain set of other windows, or you can even handle an event that lets you programmatically decide on the fly.  Thus with those kinds of features, you don't have to define your initially-hidden windows in XAML when using MVVM.

>>Well the scenario of having a tool window in XAML that isn't meant to initially be there isn't something we support. You should only have tool windows in XAML that are meant to be open at app startup, or as a default.

...All of my GUI is defined in XAML - isn't that the whole purpose of XAML, for defining GUI?  If not in XAML, then where?

There's a large number of ToolWindows - some visible initially, some not. Those which are shown or hidden initially might be revised per customer feedback - i.e. a panel that users find themselves using frequently should be there at launch, and less-common ones should be hidden (but accessible via menu).

Hi Justin,

Tool windows are easy to create programmatically and can be created and shown in a couple lines of code, assuming you have a UserControl predefined for the content of the tool window.

That being said, you do have a valid point that we should try and support this scenario since it could be helpful in some scenarios.  We'll try and squeeze it into the 2016.1 version before it is finalized.

That would be great - I'll be keeping my fingers crossed! :)  Because yeah, I was gonna say - with all due respect, the way it behaves now really does kinda present as a bug.

(i.e. it's a read/write property called "IsOpen," implemented for the purpose of DataBinding such that setting it true/false corresponds to opening/closing the window...except that it's actually only functional for 50% of scenarios - if it was true initially.  If it happened to have been false initially, then it no longer functions ;))