Develop Reference

Multiple listview objects at the same position

I have a chart with multiple chart areas and I want to have a listview where the user checks different signals, that are being plotted in the areas.
Since I want some signals to be displayed in more than one chart areas, I need the listview to reset every time the user selects a different chart Area.
To achieve this I think it is a good idea to create a new listview every time the user selects another chart area and bring the new to front.
My question is , how can I create multiple listviews at the exact same location, and also if someone has a better idea to this.

As you know, you can define the listview in code and do all the styling by hand or you can create a customControl for that.
But then, when the load event of your main form is fired, you create all the listview/customListViewObjects that you need and place them in the same location with the same size by setting their Location and Size property. Finally, you can use BrintToFront() on the required listview when an area is selected.
There are some other ways, but they aren't beautiful in winforms.
A) you can create a tab control with N tabs, then place a listview in each tab and set the tabControl style to the tab header/title is not shown. But as far as I remember, the tabControl will add a border frame that your cannot get rid of.
B) If you don't have many areas and its number is not going to change, you can create the listviews manually in your form editor, and place them wherever in your form (with the appropriate parent, of course). Then in your load event, you can set their location and size properties to the one you need. This is kind of ugly and you may see the controls moving when the form is loaded if you are not careful.
On the other hand, you can just have one listview and then, when the area is clicked you can reload all its child controls for the different signals.

WPF ListView scroll whole page (seen items) by button click

I've created a listview in WPF. The items in there are changing their backgroundcolor by clicking, in this case i deactivated the listview prop 'Focusable'.
For my usecase (on a touchscreen) i want to hide the scrollbar and just scroll by clicking an up/down button at the bottom. One click should scroll the whole page (UP/DOWN) and show the next (so far hided) items.
I'm seraching for a flexible solution and don't want to calculate pixels or smth like that (also the items haven't a fixed height, also the window)
Thanks in advance

First off, it might benefit you to take a look at How do I ask a good question?. Specifically, in your case it would be easier to understand the sitution if you included some of your XAML. However, I do think I have a solution for you.
ItemsControls like the ListView support "content scrolling", meaning the ability to scroll by content/items instead of by pixel. This question gives a solution to finding which items are currently visible in the ListView by accessing the internal ScrollViewer. ScrollViewer.VerticalOffset will tell you the index first visible item and ScrollViewer.ViewportHeight will tell you how many items are visible. To scroll to the "next page", you should just need to:
ScrollViewer.VerticalOffset += ScrollViewer.ViewportHeight;

How do I get the total height of all items inside an ItemsControl?

I've tried accessing rendersize, actualheight, height, nothing is providing height of all items inside my ItemsControl element - in fact the only property returning a value is ItemsControl.ActualHeight; however this is returning the same size as the parent StackPanel element, which is nested inside a grid.
Is there any way to calculate or pull the full height of an ItemsControl element with all Items generated/rendered? Currently if my window renders at 1920x1080 and I've got a ton of items in my ItemsControl - the ItemsControl actualHeight always matches the windows height; I need to be able to determine the full length of all my items and how it compares to the window size.
Thanks really appreciate your time and assistance!

ItemsControls are complicated entities, you see, there is progressive/incremental loading built in to those controls, it is part of a system called Virtualization, and it an extremely widespread across all UI systems, when you scroll down on BinGooglGo image results you get progressive loading for example.
Not all items inside the ItemSource are rendered at the same time, instead only what the user sees have a 'physical' form.
It is often for example that, A typical UWP ListView will only render the exact amount of items that fit into the current ViewPort (visible area) plus about 10-20 more items south and north of of the viewport in preparation of a scrolling action.
Edit:
But because i dont like leaving my answers not being solutions, i will showcase the following albeit Anti-Pattern :
Wrap your ItemsControl with a Scrollviewer, it will cause an immediate load of all of its contents.

Virtualize GridView inside ScrollViewer in Windows Store App

I have the following application:
I am developing a Windows Store app in which I need to show a big grid filled with buttons. The content of the buttons are some numbers and when I click any of them, I open a Popup with editor, where I edit those numbers. For that purpose I use a GridView, I put an ItemsWrapGrid as ItemsPanel. This makes the grid look exactly as I need it to look. I put the GridView inside a ScrollViewer, because I need to scroll the grid in both directions, since it has a lot of elements. Also I need to have the pinch-to-zoom effect that the ScrollViewer gives out of the box. I need to change the ItemsSource for that GridView when the user chooses different source in a ListView next to the GridView.
The problem:
Putting the GridView inside the ScrollViewer breaks the Virtualization inside and this has a major impact on my performance. When I switch the ItemsSource of the GridView, it takes more than 3-4 seconds for the rendering and during that time, the UI is frozen.
My question:
How can I keep the awesome stuff that the ScrollViewer gives me and also keep the virtualization? Because when I remove the ScrollViewer, changing between the ItemsSources happens almost instantly.
Any idea?

You'll be best off implementing virtualization yourself since you're trying to use the GridView far from the use cases it was designed for.
Put a Canvas in a ScrollViewer that does both pan and zoom and handle view change events on the ScrollViewer by laying out item containers inside and around the viewport. Avoid unnecessary changes too, so keep containers in place if they are to stay realized between view change events and recycle containers that are leaving the viewport neighborhood.

What would you suggest for building such a control in WPF?

I need to build a WPF control that looks somehow similar to this:
alt text http://img251.imageshack.us/img251/6857/circle.png
Where each color should be clickable and resizable (or selectable).
This control will be used to set modes on the hours of a day.
I've thought about making 24 buttons that would be arranged in a circle:
alt text http://img684.imageshack.us/img684/2184/buttonsk.png
Another idea was to draw a complete circle and calculate user mouse click's position for the selection and draw several circles to represent the data.
Any other/better ideas on how to build this?
(please excuse my poor drawing).

I think you would get odd edge-effects with multiple overlapping or touching controls. So I would make a single custom control to do this. It would convert the mouse position on button down to a slice, and then do the appropriate action.
With a single control, you could also come up with a rational way of dealing with keyboard input and for showing selection and allowing for multi-select behavior.

It sounds like you want a customized ListBox (multiple items that are selectable/clickable). For the layout you would want to use some type of RadialPanel as the ItemsPanel. You probably also need to change the ItemContainerStyle to make your ListBoxItems look like what you have above, probably with some triggers to change colors based on selection state. Depending on what behavior you need from your items you may need to create custom ListBox/ListBoxItem derived custom controls but in a lot of cases the built-in behavior will get you a long way. To reuse it as a single unit you could wrap up the ListBox with its 24 hour items and customized templates in a UserControl and expose the selection data in whatever form you need as a Dependency Property (like an IEnumerable of the data items representing the selected hours).
Does that help you get started?