This project is read-only.

Some AD 2.0 issues

Nov 12, 2012 at 4:24 PM
Edited Nov 12, 2012 at 4:55 PM


I want to start by thanking you for keeping the project alive. It's a great library and works very well for our project. (some examples here: ).

However, we've got serious performance issues that were probably related to dependency property bindings. Interestingly, the effect could be resolved by undocking and redocking a panel.

So it was great news that you actually did a rewrite. I got most of the project running after an hour or so. A migration help would have been useful, but with the example-projects it was not that difficult to figure out how to the different elements got renamed.

A side note regarding the project: I personally find the LayoutDocument the only reasonably unit to work with. My personal favorite of dockable UIs is Adobe's After Effects, and luckily, you can build just that from document-panels. I wonder, if MS ever did any usability tests on the Tabs above and below panels at the same time. I personally find the concept utterly confusing. (In your example for the AD 2.0 documentation, the "Sorgente" and "Disegna" tabs irritate me a lot).

Thanks for your work! 

So, now for the problems:

  1. I completely failed to get DockWidth and DockHeight to work. In the example project, I noticed that missing widths or widths like "2*" break the calculation completely. But for my own project, the layout is always distributed evenly for all panels in the application. Any idea how I could fix this?
  2. Is there an easy way to fluidly update the layout when dragging splitters? I know, you basically, try to clone Visual Studios behavior (which I can't understand), but the update is fast enough to dynamically update when resizing the MainWindow, so why not always do so?


A small update:

When adding an Loaded-Handler for App.MainWindow, I noticed, that all dimension I set in the XAML-Code got reset to "*". Ofterwriting the dimensions manually in the Handler, worked.


BR and greetings from Berlin,


Nov 13, 2012 at 1:56 PM
Edited Nov 13, 2012 at 1:57 PM

I tried a little more to get migrate to AD 2.0 but additional to the size/layout problems described above, there're quite a lot of issues related to dragging / rearranging panels. Please have a look at the following video-capture:

pannel-problems from framefield on Vimeo.

Does anyone experience similar symptoms? Obviously, this worked perfectly fine with AD 1.3.

Any comments or ideas are welcome.


Nov 13, 2012 at 2:23 PM


could you please try to make a test using a different theme. Also is there any reason why you use only Document views?


Nov 13, 2012 at 3:14 PM

I tested the VS2012 Theme. Dragging/rearranging panels seems to be stable here. Also, the docking-hint-overlay is really nice. Would be great to have this in the ExpressionBlend-Theme.

Interestingly the "snap back" of the horizontal-orientation panel width still happens. But only of the vertical spliters. The vertically oriented layout panels (e.g. on the left side with color/library) keep their heights.

Regarding your second question: I personally think that the differentiation between different types of panels is over-engineering. I'm convinced that most common users will be more irritated than they would benefit from the difference. Since we're building a 3D-content creation tool,  I had a look at most available existing solutions, and none of the them incorporates the idea of having tabs sometimes at the top and sometimes at the bottom. Since you can mix the two types in AD, I had to decide for one of the two. Back then (some theme with AD 1.2) Documents were on top, so the choice fell on them.

With the later Themes I could have also went with the Tool-Panels.

I'm pretty sure, there must be some reasoning behind separating tool-panels from document-panels. But as long as I fail to see them, I stick with one type, if it gets the job done.

Interestingly, the bottom tabs seem to be a very common pattern in dev-environments: . It would be an interesting story to learn who came up with this pattern and how long it's going to survive. One obvious drawback is, that you have to waste height by repeating the title of the panel with a headline and some people will fail to understand that visual hierarchy (this headline only being valid for the active tab).

Nov 13, 2012 at 3:29 PM

On the After-Effects UI: This is my personal reference how an intuitive dockable UI should work:

Highlighting the drop zones instead of having an additional overlay is a really really clever idea.