We Keep Coding

Wpf design ; multiple views in one window

Im building an application where I want to head for a design, that could remind of a dockpanel.
What I want, is having buttons in the left side (or left panel) representing different areas of the application (e.g "Milk", "Bread") and then have different "views" in the middle-panel.
What I already have tried, is making an application with a "Frontpage", and buttons changing the whole window/usercontrol - this however will not give me static areas/panels.
I do not want to use a tabcontrol with the tabtitemstrip being vertical - however it is kinda the same functionality im looking to have.
Any ideas?
Below is a picture with the wished design, to kinda give an idea of my thoughts.. Any help appreciated :)
http://s57.photobucket.com/user/RolleKn/media/wpfdesign_zps3737b014.jpg.html

If you use WPF, use ContainerControl or ContentPresenter for that.
In general, "switching Visibility On/Off" is not a good way to go. It forces the UI to create all objects, even those invisible ones, and to handle their data and events, etc.
And you need to switch it all manually.
WPF provides you with many mechanisms that can save you this. Some are smarter than others, some not.
One of the most basic mechanism in WPF is the Control and its Template property. You can replace whole your Grid+Contents+SwitchingVisibility idea with a single Control and switching its Template:
<Window.Resources>
<ControlTemplate x:Key="panel1"> ..carrots.. </ControlTemplate>
<ControlTemplate x:Key="panel2"> ..cucubers.. </ControlTemplate>
<ControlTemplate x:Key="panel3"> ..donkey.. </ControlTemplate>
...
</Window.Resources>
<Grid x:Name="LayoutRoot">
<Control x:Name="foo" />
</Grid>
Now, if you get the foo and set its .Template and set it to panel1, then the "carrots" will show up. if you set it to panel3, donkeys. And so on.
It's very powerful, but it will not be really handy due to some other things I won't cover. There are books and tutorials that explain Templates in depth. Also, this mechanism is really not designed for such task. It's the most basic one, and a good thing to know if you want to work in WPF, but there are more suitable ones here.
Second next powerful and still basic mechanism is ContentControl/ContentPresenter. They work almost in the same way (actually CC uses CP internally), so I'll skip it.
ContentControl is a smart control that knows how to automatically select a correct Template with respect to the data you are tryng to present.
So:
<Window.Resources>
<DataTemplate DataType="CarrotData"> ..carrots.. </..>
<DataTemplate DataType="CucumberData"> ..cucubers.. </..>
<DataTemplate DataType="DonkeyData"> ..donkey.. </..>
...
</Window.Resources>
<Grid x:Name="LayoutRoot">
<ContentControl x:Name="foo" Content="{Binding ..}" />
</Grid>
Note the change from 'ControlTemplate' to 'DataTemplate'.
Now, with this setting, you don't even need to switch templates manually. You just get the "foo" and set its Content to either:
a CarrotData object, that contains the carrot-related data
a CucumberData object, that contains the cucumber-related data
a DonkeyData object, that contains the donkey-related data
Once you set the data to be shown (i.e. foo.Content = carrots[5]), the ContentControl will pick the relevant template to be shown.
You can bind the Content property to just about anything. If you have some dataclass that contains carrots/donkeys and has a property CurrentThing, you can bind to it and ContentControll will switch the views automatically along with the changes to CurrentThing.
That's basics. There's much more to it, in almost any point I tried to briefly cover. For now, leave ControlTemplates. Read about DataTemplates and Bindings. Read about ContentPresenter (shows 1 template for 1 item) and ItemsControl (shows N items+templates). Then, read a little on MVVM pattern.
You will quickly see that "having everything in one Grid" and "switching Visibility" is an odd way to do it.
However, I wouldn't be fair if I didn't mention that everything has a cost included. Extensive use of templates and bindings makes your app a bit slower compared to what you could get when you do everything manually. But usually, doing it manually is just not really worth it.

Preferred behavior when going from filled to snapped Visual State

I am currently implementing a few snapped views, and I've ran into a problem I couldn't find an answer to. Perhaps you beautiful minds can help me out.
When I drag my app from a filled state to a snapped state, there is a period of about 1 - 1.5 secs where the old "filled" view is still displayed in the snapped viewspace. Doesn't look good! I would imagine there would be a standard behavior that should be applied here. Do I show the splash screen? Do I animate in items (and if so, what event should I listen for)?
Thanks for all help!
Edit: Here is a bit of simplified code from one of my views who experiences this lag - a search results page:
<Grid x:Name="LayoutRoot">
<Grid x:Name="FullViewGrid">
<!-- Two GridViews containing up to 27 items each (not very advanced) -->
</Grid>
<Grid x:Name="SnappedViewGrid">
<!-- Two ListViews doing the same thing, with different item templates -->
</Grid>
</Grid>
Basically I'm implementing my own spin of the standard Search Contract template given in VS2012. I have a feeling the CPU is being stressed a bit too much while rendering these changes in the UI - and that's why things aren't going too smoothly.

Yeah, so this is something you are doing wrong. SnapView doesn't have a delay like that. If you are interested you can review my SnapView walkthrough: http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html
Without a code sample from your app, this is the best I can offer right now. But hopefully this will be all you need to get on the right path for SnapView. Best of luck!

Subclassing FrameworkElement in Silverlight 4.0 - A Measure Pass Question

I currently have an issue in Silverlight where I want to detect the change in size for an element, and react to it. However, listening with .SizeChanged is actually not sufficient, as often I get a flash of the element at the size it's changing to, before the functionality in the .SizeChanged is called. So I have perhaps a two-fold question.
My intention is to use the Measure pass to calculate the manipulations I want to apply before the size is visually changed, so that I can eliminate this flickering effect. As far as I'm aware, the only way to do this successfully is to create a UIElement that does these calculations on the Measure pass, before Measuring the rest of these elements.
As such, I was hoping to create a really light UIElement by extending off FrameworkElement. However, I can't get the stupid thing to display anything. I'm under the impression that at the FrameworkElement level, a subclass would require adding the content to the VisualTree and I can't seem to work out how to do that.
I was hoping to avoid extending off UserControl, or Panel, as they are far heavier than what I need, with so much extra functionality I dont want. I merely want to catch the Measure pass and perform some work there.
So, is it possible to extended off FrameworkElement in Silverlight 4.0 and actually render something? If not, is it possible to listen for/interrupt the measure pass another way?

You cannot manually add content to the visual tree - this functionality is only exposed to built-in Silverlight controls.
In such a situation, you should derive from Control and specify a default template for this control to use - in the default template, specify the desired contents of the visual tree.
To allow a default template to be used, you should specify DefaultStyleKey in your contructor and give it the value of your control type. E.g. DefaultStyleKey = GetType().
Then, you can specify a style such as this, in e.g. Themes/Generic.xaml
<Style TargetType="my:MyControl">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="my:MyControl">
<Rectangle Width="100" Height="100" Fill="Red" />
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
Or if your control is a content-presenting control, just derive from ContentControl and it takes care of all the plumbing - you just need to set Content to whatever you wish to display and your subclass will only need to perform the measure-pass override logic.

Custom ContentControl in WPF

I think I'm asking for a lecture on the proper application of WPF here but I'm going to take my chances since I'm at my wit's end. I think this is probably largely a result of my lethargy in fully embracing WPF templates and styles so I'm happy to listen to any such lectures.
I'm writing a sort of audio editor / event orchestrator. I've got a track editor that I'm fairly happy with. However, I built it largely out of custom controls (I know, this is probably a WPF sin). In keeping with that theme, I want to make a standard header for the tracks but I want the individual track "types" to be able to define what goes in that header. I thought a control that defines a sort of "grip" on the edge and then allowed the implementer to "fill in" the substance would work well. However, I have no idea how to do this in WPF without using styles and even if I end up using styles, I would like to understand this.
This probably comes down to wanting a sort of exemplar implementation of a simple ContentControl control (e.g. a button) and not being able to find one (other than AvalonDock, which ultimately uses - correctly i'm sure - templates for this). In my head, the xaml looks something like this:
<ContentControl x:Class="TestArea.CustomContentControl2"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="300">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
<TextBlock Text="Hello"/>
<ContentPresenter Grid.Column="1"/>
</Grid>
But of course, that doesn't work. I'm fairly sure I could pull the same thing off by playing tricks with overloads behind the scenes, but it would be nice if I could do something like this. Do I really have to put all my terrible, procedural ways behind me and use these styles you speak of? If so, can someone at least tell me what that button looks like down in the framework?

Here is a complete example of deriving from ContentControl to accomplish what you want: Creating Customized UserControls (Deriving from ContentControl) in WPF 4
Pete's ContentPresenter is doing the same thing as it does in your example.

Using styles allows you to seperate functionality of a control with representation of a control; such as the Button.
Think as a control at the start as nothing more then functionality. A simple class containing predefined events, properties, etc... Once that control takes on the job of becoming part of a visual tree it now needs a visual identity. It didn't need one previously; however now it does. Defining a default style allows that control to now have a visual representation which it did not need prior as it was not living within the visual tree.
Ignoring styles would be like ignoring CSS when making use of HTML.

WPF: Textbox scrollbar has no thumb

My textbox is the only control on a window, which is a part of a bigger application. The textbox contains a certain amount of text, large enough to show vertical scrollbar. The scrollbar appears, but without a thumb:
I can still scroll the contents, either with mouse wheel or by clicking the arrow-buttons repeatedly.
When I create a new project with the same window and textbox the scrollbar works as it should. The same happens with a WrapPanel. Do you have ideas what could be spoiling my existing project and causing this issue? In generic.xaml I found some styles overriding the defaults for scrollbar and scrollviewer, but even totally clearing generic.xaml didn't help.
Thanks in advance!
EDIT: right, the code. It's XAML only (no c# backing code).
<Window x:Class="TextBoxTest.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" MaxHeight="200" MaxWidth="200">
<TextBox x:Name="textbox" MaxLines="2" MaxHeight="50" VerticalScrollBarVisibility="Auto" TextWrapping="WrapWithOverflow">
Useless text..... asdasdasda ssssssssssssss sssssss ssssaokdoka sdojwoandowm nxaofwha398ua ozmca3u0a3j3 a80a9fu 03 u0sf u0s9jf4s 0cuj wuf0j w40 fcjw cujwfj9 c9 u49 wsuc j9w3
3089w 9f8u4wfv 0sf ufw0u w0fuw0 fwu f0uw 09djcazp zopf h43 wofh FYHFWFH WOWY HWO H wohg fujg 4g fugj 4 g0 4
4w fw4 f3f g555u45y 55 some more some moresome more some moresome more some moresome more some moresome more some more.
</TextBox>
</Window>

The answer is astonishing!
Just after I'd started to suspect it might be a WPF bug, I found this forum thread.
Guy who asked the question says: "My application uses a directx renderer from a DLL that's written in C++". Mine does almost the same with the difference that my renderer is written in C# (MDX) and uses D3DImage interop.
Following steps mentioned in the thread above, I moved DirectX initialization from OnInitialize() to Loaded event callback of the main window and now scrollbars regained their expected appearance. It seems that GUI must be displayed first, before the renderer is initialized.
So I guess it's reasonable to talk about a bug in this case.

It seems like a style problem. Remove explicit style setter from the TextBox (check both XAML and code behind). If TextBox has no explicit style, search for implicit styles (defined via TargetType="TextBox" or TargetType="{x:Type TextBox}" and/or x:Key="{x:Type TextBox"}).
Try snooping your application and check ScrollViewer's visual tree. It may give you some insights where to look.
Hope this helps.

At a guess: your TextBox is inside a StackPanel. If you want more than a guess, you'll need to provide code.

You can solve the problem adding CreateFlags.FpuPreserve during the creation of your D3D Device
Example:
this.device = new Device(0, DeviceType.Hardware, this.handle,
CreateFlags.HardwareVertexProcessing |
CreateFlags.PureDevice |
CreateFlags.FpuPreserve, this.pparams);