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
Related
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.
When dragging a window around if it went to a specific area via DragMove i wanted to show a semi-transparent window overlay in that region.
Showing the window worked fine, but it would always come up on top of the window i was dragging.
I tried various things such as .focus/.activate after i show the overlay, but they didn't work.
Each window had WindowStyle="None" Topmost="True" ShowInTaskbar="False" and the overlay window even had IsHitTestVisible="False" Focusable="False". Though, the overlay would still get focus when it's visibility was toggled on.
The only thing i found to work was to hide my main window and then show it again. Though, i didn't want it to flicker, so i disabled the dispatcher while i was doing it. This ended up working beautifully. I couldn't find any similar issues online so i figured i'd post this to help the next person.
private void showOverlay()
{
//show the docking window
_overlayWindow.Visibility = Visibility.Visible;
//problem here will be that the overlay window will be on top of main
//this.focus this.activate +other efforts did not work to bring main back on top
//only thing i could find that would bring the main win on top is to hide/show it again.
//i wrap this hide/show in a disabled dispatcher block so that the window never really gets hidden on screen
using (var d = Dispatcher.DisableProcessing())
{
this.Visibility = Visibility.Hidden;
this.Visibility = Visibility.Visible;
}
}
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
I have a minimized WPF window. I click the item in the taskbar to maximize. It makes a little audio ding, then I try again, and again. Usually about the third try it will maximize. What could cause it to refuse my initial maximize attempt?
One possibility is that you have some code that's changing the value of the ResizeMode property to NoResize.
See this page for more: http://msdn.microsoft.com/en-us/library/ms748948.aspx
Second, you might be overriding OnStateChanged and not calling base.OnStateChanged() consistently.
Third, you may have something hogging the UI's thread during your first attempts. Once that task--whatever it is--stops blocking then WPF can repaint the window in restored/maximized state.
I had a similar problem when trying to manually maximize a custom window.
The solution was to put the next code in my maximize button...
this.SizeToContent = System.Windows.SizeToContent.Manual;
this.MaxWidth = double.PositiveInfinity;
this.MaxHeight = double.PositiveInfinity;
this.Width = double.NaN;
this.Height = double.NaN;
this.WindowState = WindowState.Maximized;
Where 'this' referes to the Window.
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...