In my scenario I have a window which I want to use to display on two different ways. One way when the window has WindowState = WindowState.Normal; and the other way where the window has Normal or Maximised state.
I want to save the Size and Position of these two window modes so for the user it would seem like two separate windows.
I have two different issues around this.
1) When I initialize the window after Show() has been called, there is a small flicker which on slower machines isn't such a short flicker. In order to fix this I wanted to set up the window while it is hidden like so:
((SecondWindowViewModel)this.DataContext).LoadWindowPosition(mode);
this.Show();
if I do this an even worst problem comes up
2)In this case window 1 which is in normal mode has some random height set on drag after window 2 has been closed in Maximized mode.
I've created a sample application what you can find here, where you can see the exact problem, I've also written down the steps to reproduce as well.
EDIT
Implemented Maxims Changes and removed unnecessary references
Haven't had yet the time to completely solve your issue, but one issue you have in your code is that you do not set the window state accordingly to your mode. In SecondWindow.xaml.cs, your code should look like this:
if (mode == WindowViewMode.Normal)
{
WindowState = WindowState.Normal;
}
else
{
WindowState = WindowState.Maximized;
}
if (this.IsVisible)
{
this.Hide();
}
else
{
((SecondWindowViewModel)this.DataContext).LoadWindowPosition(mode);
this.Show();
}
Still need to take a look at the problems your LoadWindowPosition is causing.
Related
I try to create a window, that can be moves or resized via multi-touch gestures. I tried it this way. I captures the TouchDown-Event of the window and saved all active TouchDevices in a List, to know which TouchDevices are active. I catch updated and deactivated event of the TouchDevices to know when they are moved and when they are deactivated. I save the Left and Top Property of the Window and the position where the TouchDevice started and everytime the Updated event is called I move the Window to the new Position relative to the new position of the TouchDevice. This works if I move the finger. But if I don't move the finger (or just very little) the window suddenly began shaking (moving chaotically) and then soon disappears to a position outside of the screen.
I think the problem here is, that the function "GetTouchPoint" of the TouchDevice only give relative coordinates related to the window (even if I set the parameter null instead if the window reference). And because the Window moves the relative position of the TouchDevice (that doesn't move) changes too. So I did a research but wasn't able to find a way to determine the screen coordinates of the touch device.
So I hope anyone can help me how to get the absolute coordinates of the TouchDevice. Or can help me find another way to "DragMove" the window with touch.(I tried DragMove, but that only works for mouse clicks, not TouchDowns) Also I like to resize the window when two Touch Devices are active and therefor I also need absolute coordinates because otherwise same effect happens.
I ran into this issue because my taskbar is on the right edge of the screen, effectively pushing the maximized window to the right. This issue also arises when the application's window is not maximized, and floating somewhere on the screen.
Here is an extension method that fixes the coordinates based on the application window's position.
public static Point FixCoordinates(this Point point)
{
var left = Application.Current.MainWindow.Left;
var top = Application.Current.MainWindow.Top;
return new Point(point.X + left, point.Y + top);
}
You may want to pass in a window that hosts your touched control as a parameter. In my case it is application's main window.
Also, since you tagged the question with "multi-touch", here is a method which averages multiple touch coordinates:
public static Point GetAverage(this IEnumerable<Point> points)
{
var averageX = points.Average(p => p.X);
var averageY = points.Average(p => p.Y);
return new Point(averageX, averageY);
}
And I use it in the code like this:
private void TouchAdornment_TouchDown(object sender, TouchEventArgs e)
{
var touchPosition = (sender as UIElement).TouchesOver.Select(t => t.GetTouchPoint(null).Position).GetAverage().FixCoordinates();
}
I have a panel and on that I've a picturebox. There are around 20 labels that I've to show in the panel. I want the background of Label to be transparent ie the image in picturebox is shown and the label displays only the text.
Now since labels do not exhibit true transparency I made the labels child of picturebox
this.lbl1.Parent = pictureBox1;
This has solved my immediate problem but now when the form loads, all the labels take a while to become visible and do so one at a time. I'd appreciate if you guys can give some solution for this.
Thanks in advance
The standard cure for flicker is double-buffering. But that cannot solve this kind of flicker. It is a different kind, caused by having multiple windows overlapping each other. Each label is its own window. When the form needs to paint itself, it draws its background leaving holes for the child windows. Each child window then takes a turn drawing itself. And their child windows draw themselves next. Etcetera.
This becomes noticeable when one control takes a while to draw, no doubt your picture box. Especially when it displays a large image that needs to be resized. The holes for the child windows stay unpainted while the picture box draws. They have a white background, black when you use the form's TransparencyKey or Opacity property. This can contrast badly with the image in your picture box, that effect is perceived by the user as flicker.
One immediate cure is to not use controls so you don't pay for their window. A Label is very convenient but it is a massive waste of system resources to burn up a window just to display a string. You can simply implement the picture box' Paint event and draw the strings with TextRenderer.DrawText(). PictureBox has double-buffering turned on by default so the image as well as the text is drawn completely smoothly, no more flicker. The obvious disadvantage is that you lose the convenience of point-and-click, you have to write code.
There are other fixes possible. One of them is to prevent the picture box from leaving holes for the child windows. It will draw the entire image, the labels pop on top of them. That's still flicker but not nearly as noticeable. Add a new class to your project and paste this code:
using System;
using System.Windows.Forms;
internal class MyPictureBox : PictureBox {
protected override CreateParams CreateParams {
get {
var parms = base.CreateParams;
parms.Style &= ~0x02000000; // Turn off WS_CLIPCHILDREN
return parms;
}
}
}
Compile and drop the new picture box control from the top of the toolbox onto your form.
Yet another possible workaround is to make the form and all of its children double-buffered. This doesn't speed up the painting at all but all of the windows get rendered into a memory buffer, the result is blitted to the screen. You'll notice a delay but the window suddenly pops on the screen. This is called compositing. Winforms doesn't support this directly since it can have side-effects but it is easy to enable. Paste this code into your form class:
protected override CreateParams CreateParams {
get {
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000; // Turn on WS_EX_COMPOSITED
return cp;
}
}
Supported by XP and later. Watch out for painting artifacts.
or you can ditch the labels and draw the text yourself:
private void pictureBox1_Paint(object sender, PaintEventArgs e)
{
TextRenderer.DrawText(e.Graphics, "Label1", SystemFonts.DefaultFont,
new Point(10, 10), Color.Black, Color.Empty);
}
The label does not support transparency, you must create your own unique custom control, you can see these code examples.
http://www.codeproject.com/KB/dotnet/transparent_controls_net.aspx http://www.codeproject.com/KB/vb/uLabelX.aspx
Bye
In my WPF app, I have WPF windows that can open other WPF dialog windows, which I do as follows:
PickForEveryone PickForEveryoneWindow = new PickForEveryone(sSelRecipe, selMRM.sDay, selMRM.MealTypeID);
PickForEveryoneWindow.Owner = this;
PickForEveryoneWindow.ShowDialog();
Where PickForEveryone is defined as:
public partial class PickForEveryone : Window
and
<Window x:Class="PFWb0.PickForEveryone"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:dg="http://schemas.microsoft.com/wpf/2008/toolkit"
ShowInTaskbar="False"
Title="Pick Recipe For All" Height="536" Width="441"
WindowStartupLocation="CenterOwner">
And contains a Grid with a DataGrid and a few buttons and check boxes.
Which works fine on my development computers. However, my client keeps seeing the dialog windows leave part of their display as visual litter on top of the parent window when the dialog window closes. That is, only some of the window undraws when ShowDialog() returns.
I tried adding this.InvalidateVisual(); below the above code, but it didn't solve the problem.
I also saw a suggestion here (for another kind of WPF display problem) to call OnRender() to force a redraw, but OnRender requires a parameter of type DrawingContext, which I don't know how to get.
So, I am asking if anyone knows how to either fix the display problem in the first place, or how to recover from it by getting WPF to redraw a window.
Update: As seen in comments to suggested answers below, I still have no solution that works on my client's computers, and my workaround (of having the windows dodge each other) is no longer enough. The only thing that works is to minimize and maximize the polluted underlying window.
I had a similar problem on a specific computer with an ATOM N270 processor.
The problem seamed to be linked to the graphic hardware acceleration.
To deactivate the accelaration, just add this to the registery (this will deactivate hardware acceleration for all WPF applications) :
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
I had to create the Avalon.Graphics folder.
DisableHWAcceleration is a DWORD that has to be set to 1.
This had solve my problem, if I reactivate the acceleration, the problem come back.
Hope this helps.
References :
Guidelines for troubleshooting graphic issues in WPF applications : http://msdn.microsoft.com/en-us/library/aa970912(v=vs.90).aspx
Graphics Rendering Registry Settings : http://support.microsoft.com/kb/963021
This ugly code works for me:
void RefreshWindow()
{
switch (WindowState)
{
case WindowState.Maximized:
{
double oldWidth = Width;
Width = System.Windows.SystemParameters.PrimaryScreenWidth - 1;
WindowState = System.Windows.WindowState.Normal;
WindowState = System.Windows.WindowState.Maximized;
Width = oldWidth;
}
break;
case WindowState.Normal:
if (Width > 1)
{
Width -= 1;
Width += 1;
}
else
{
Width += 1;
Width -= 1;
}
break;
case WindowState.Minimized:
default:
// no action necessary
break;
}
}
So I have been looking for an answer to this on the MS forums, and apparently, variations of this question have been a asked for a few years now.
Sometimes, they say, the problem has to do with video drivers, of all things, although in my case, my client has recently updated his video drivers.
My impression is that Microsoft thought they designed WPF so that a developer should never need to do such a thing as force a redraw of the display, so they make no way to do so by design. Of course, when things go wrong for whatever reason, this means there is no straightforward way to do so. And the ways that seem like they might do so (such as InvalidateVisual()), don't.
But I did find one hack that does work. Well, two. The ugly one is to tell the window to minimize and return to normal. But that results in a visual animation of it doing so, which is not ideal. In my case, it also made it hide behind other open windows, requiring me to make it go topmost. But is does solve the problem, in a jarring way.
Code after ShowDialog:
this.WindowState = WindowState.Minimized;
this.WindowState = WindowState.Normal;
this.Topmost = true;
The better hack, looks a bit like this:
Code outside:
public delegate void NoArgDelegate();
Code after ShowDialog:
this.Dispatcher.Invoke(
System.Windows.Threading.DispatcherPriority.Loaded,
(NoArgDelegate)delegate {}
);
Presto ala kazzam!
This solution works, but it is not very pretty (easy to see that dialog is minimized and then set to normal).
this.WindowState = WindowState.Minimized;
this.WindowState = WindowState.Normal;
this.Topmost = true;
So far nothing I have tried actually works on my client's computer.
I have a new fix (workaround hack) attempt in for client testing, which involves moving the window away, and trying to make it actually take effect by launching an empty window just before I close the dialog window. Sigh...
Our application has a number of objects on a canvas; the canvas is contained in a scroll viewer. We also have a slider control and some buttons, always centered at the top of the window.
I am trying to print the application by capturing a bitmap of the app, but without any 'decorations' -- slider, buttons, or scroll bars.
_scrollViewer.HorizontalScrollBarVisibility = ScrollBarVisibility.Hidden;
_scrollViewer.VerticalScrollBarVisibility = ScrollBarVisibility.Hidden;
var s = xSlider;
s.Visibility = Visibility.Collapsed;
var b = xPlusButton;
b.Visibility = Visibility.Collapsed;
b = xMinusButton;
b.Visibility = Visibility.Collapsed;
b = xButton;
b.Visibility = Visibility.Collapsed;
The slider and buttons are hidden, as expected, but the scrollbars are not.
I suspect the application needs to redraw the layout in order to hide the scrollbars. Is there a way to make that happen? This is made more complicated by the fact that the print operation in SL 4 must be initiated by a UI gesture; there is no way (AFAIK) to initiate programatically, so this redraw must happen in one of the PrintDocument event handlers.
Thanks for any suggestions....
Try following,
canvas.InvalidateMeasure();
canvas.InvalidateArrange();
You can alternatively use WritableBitmap to capture runtime image and send image to print document if in case print document is ignoring render transform.
Also if you are using WritableBitmap to capture the element then you should give RenderTransform as second argument. Can you post your code to capture screen?
In addition to the InvalidateMeasure and InvalidateArrange methods, as suggested by Akash, you can try the UpdateLayout method.
The two invalidate methods will mark the control's measure or arrange as needing to be executed again, but won't necessarily do it immediately. The UpdateLayout will force it to execute some updates immediately.
It's a bit of a black box, so you may need to invalidate then call UpdateLayout. Sometimes you may just need to call UpdateLayout.
I want to achieve the same effect as Windows Media Player or Browser based Flash players which take up the ENTIRE (not even the taskbar is visible) real estate when maximized.
This works fine if the WindowState is set to Maximized and the WindowStyle is set to None in XAML so the app is started in that state. Problem is I want to start the app in a bordered window and when the user chooses, maximize as specified above. In the StateChanged handler I check for Maximized state and if this is the case I set the WindowStyle to None. This has the effect of maximizing the window but NOT covering the taskbar. The following code will make this work as I want but its a hack and I'd like to clean it up:
if (WindowState == WindowState.Maximized)
{
m_videoWindow.Maximize();
WindowStyle = WindowStyle.None;
//the following makes this work but I would like to clean it up
Hide();
Show();
}
EDIT This (from 2006 when still in CTP) mentions the problem and someone from MS states they hope to improve full screen support in the next version, have these improvements been made?
This article explains it all: Maximizing window (with WindowStyle=None) considering Taskbar.
Also worth checking out: Custom Window Chrome in WPF.
Edit: Now new, is the WPF Shell Integration Library that allows complete restyle of the window chrome without the headaches of reimplementing move, resizing, etc.
Edit 2015: Shell Integration Library is now integrated in WPF and MS retired the code
I found I could maximize to full screen (covering the taskbar) by setting the properties when creating the window (in xaml), but was not able to switch back and forth after creation. After some experimenting, I found the order the properties are set seems to matter:
public bool IsFullscreen
{
get
{
return WindowState == System.Windows.WindowState.Maximized
&& ResizeMode == System.Windows.ResizeMode.NoResize
&& WindowStyle== System.Windows.WindowStyle.None;
}
set
{
if ( value )
{
ResizeMode = System.Windows.ResizeMode.NoResize;
WindowStyle = System.Windows.WindowStyle.None;
WindowState = System.Windows.WindowState.Maximized;
}
else
{
ResizeMode = System.Windows.ResizeMode.CanResize;
WindowStyle = System.Windows.WindowStyle.SingleBorderWindow;
WindowState = System.Windows.WindowState.Normal;
}
}
}
Note that WindowState comes last in the setter.
To get this to properly work in my WPF/.NET 4.0 application I am calling this function whenever I enter or exit full screen mode:
private static void RefreshWindowVisibility(Window window)
{
if (window.OriginalWindowState == WindowState.Maximized)
{
window.Hide();
window.Show();
window.BringIntoView();
}
}
There is a flicker associated with this method, but it seems the same flicker exists when going to full screen mode on Chrome. Internet Explorer seems to take a different approach.
I don't know if this is ok for you, but you can resize the window to have the same size than the working area (that is, in most cases, all the screen except the taskbar) and locate it at 0,0 (top-left corner):
Width = System.Windows.Forms.Screen.PrimaryScreen.WorkingArea.Width;
Height = System.Windows.Forms.Screen.PrimaryScreen.WorkingArea.Height;
Left = 0;
Top = 0;
The exact definition for the WorkingArea property (from MSDN) is:
Gets the working area of the display. The working area is the desktop area of the display, excluding taskbars, docked windows, and docked tool bars.
Hope it helps