Certain elements of my application have custom resizing events, which all work. However, they are messed up by one case:
When hovering over the border of the window, so that the cursor becomes the resize handle, and you click (but do not drag), the elements resize incorrectly, and my handlers are not fired.
I've looked for such an event but cannot find anything that matches. I'd like to simply make a handler for this event to avoid glitchy resizing of my elements.
I'm using C#/WPF, with .NET 4
xaml for the window:
<Window x:Class="XHealth.MainWindow"
Name="mainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:DataGridTemplateSample"
xmlns:XH="clr-namespace:XHealth"
xmlns:toolkit="http://schemas.microsoft.com/wpf/2008/toolkit"
SizeChanged="update_size"
Title="XHealth" Loaded="Window_Loaded" WindowState="Normal" WindowStartupLocation="CenterScreen" mc:Ignorable="d" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" SizeToContent="WidthAndHeight" WindowStyle="ThreeDBorderWindow" MinWidth="650" MinHeight="648" Width="Auto" VerticalAlignment="Top" DataContext="{Binding}" PreviewKeyDown="Window_KeyDown">
Event handler:
public void update_size(object sender, RoutedEventArgs e )
{
if (resultsTab.IsSelected){
Grid.SetRowSpan(dataGrid1, 2);
Grid.SetRowSpan(dataGrid2, 2);
}
}
This handler performs as intended, but does not trigger when the resize handle is not dragged, which leads me to believe clicking the resize handle is a different event.
Also, this only happens once - once my resize handler takes effect, clicked the resize handle has no effect.
Converting my comment into an answer:
That could be resolved by not putting any * in the Grid.
Also, if the Window is set to SizeToContent, you should only SizeToContent=Width to prevent the window from scaling endlessly.
Remove all the event handlers stuff, that's hack.
Related
I am trying to have the SizeToContent="WidthAndHeight" and WindowState = "Maximized" at the same time. I tried to change the state of my window during loading, as well as in the Constructor of the MainWindow, but no luck.
<Window x:Name="MainWindowMy" x:Class="ManyTabControls.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="Pressure Vessel Design" WindowState="Maximized" SizeToContent="WidthAndHeight" ScrollViewer.VerticalScrollBarVisibility="Auto" ScrollViewer.CanContentScroll="True" ScrollViewer.HorizontalScrollBarVisibility="Auto" Loaded="MainWindowMy_Loaded" >
<Window.Resources>
I have got a TabControl with a lot of tabs, in the design viewer, tabs are flowing down into different rows. And when I change the width of the TabControl so that the tabs be in the same line, then they go outside the boundary of the MainWindow. And if I set the width of the Mainwindow, then the MainWindow would have a constant width. That means if the size of monitor gets smaller, then part of the MainWindow that is bigger than the screen will not be displayed. I hope I made myself clear.
Thanks Eugene, I got the idea. I already tried to change the state of my MainWindow at run time, but it didn't work out (MainWindow didn't occupy the full screen).
The reason, as Eugene mentioned, is that these properties conflict with each other (SizeToContent gets the priority) so I have to turn one off in order to be able to turn the other on. Hence, to solve the problem:
private void MainWindowMy_Loaded(object sender, RoutedEventArgs e)
{
this.SizeToContent = System.Windows.SizeToContent.Manual;
this.WindowState = System.Windows.WindowState.Maximized;
}
It's not the most elegant way of doing it, but it serves the purpose for now. However, if anybody could come up with a more elegant solution, it would be greatly appreciated.
I have a window, it will do some checking before it is shown.
public class MyDlg : Window
{
public MyDlg()
{
Initialized += new EventHandler(Window_Initialized);
}
private void Window_Initialized(object sender, EventArgs eventArgs)
{
if (!/*do some checking*/)
{
Loaded += (s, e) => Close();
}
}
}
If "do some checking" fail, the above code will close my window immediately after the window is loaded. However this is too late because I can see the window just appear and disappear.
How can I close my window without showing it?
EDIT:
The one who will construct MyDlg is like:
MyDlg dlg = new MyDlg ();
dlg.ShowDialog();
But it is hard for me to prevent calling 'ShowDialog()', because they are written by other people (I'm trying to write MyDlg in some library)
How can I close my window without showing it?
Perform the check before calling the Show or ShowDialog method of the window. You could either do this in the calling code:
MyDlg dlg = new MyDlg();
//perform your check here...
dlg.ShowDialog();
...or in the constructor of the MyDlg window:
public MyDlg()
{
//perform your check here...
}
Obviously the window is already shown by the time the Window_Initialized event handler gets invoked so then it is too late to perform any check if you don't want the window to appear. You cannot close a window that hasn't been opened.
You can create splash dialog inside your new window.
And set IsEnabled=False on window/dialog.
Or if your operation is quick then there is no need for splash. Just hide your window:
<Window x:Class="Wpf.Test01.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:Wpf.Test01"
xmlns:charting="clr-namespace:System.Windows.Controls.DataVisualization.Charting;assembly=System.Windows.Controls.DataVisualization.Toolkit"
mc:Ignorable="d"
IsEnabled="False"
WindowStyle="None"
AllowsTransparency="True"
Title="MainWindow" Height="350" Width="525">
<Window.Background>
<SolidColorBrush Opacity="0.0" Color="White" />
</Window.Background>
You can see it done here WPF Window with transparent background containing opaque controls
Of course change the properties back to visible/default if everything is ok
I have a simple window:
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:self="clr-namespace:WpfApplication1"
Title="MainWindow" Height="435" Width="613">
<StackPanel>
<Canvas Name="canvas">
<self:Red />
</Canvas>
<UserControl Name="uc">
<self:Blue />
</UserControl>
</StackPanel>
</Window>
Redand Blueare very simple UserControls:
<UserControl x:Class="WpfApplication1.Blue"
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>
<Rectangle Fill="Blue" Width="100" Height="100" />
</Grid>
</UserControl>
I have created some ContextMenus:
public MainWindow()
{
InitializeComponent();
canvas.ContextMenu = new ContextMenu();
canvas.ContextMenuOpening += (sender, e) =>
{
System.Diagnostics.Debug.WriteLine(e.Source.GetType());
};
uc.ContextMenu = new ContextMenu();
uc.ContextMenuOpening += (sender, e) =>
{
System.Diagnostics.Debug.WriteLine(e.Source.GetType());
};
}
If I open the context menu on the Canvas, the Source is Red, but if I open it on the UserControl, Source is UserControl.
Any idea why?
I found this on MSDN:
ContextMenu itself is a FrameworkElement derived class, but this event will not be raised from the context menu being opened as a source. The event is raised from the element that "owns" the context menu as a property...
If I understand it correctly Source should be Canvas in the first case, but it isn't.
This behavior is covered fairly well in the MSDN documentation for the RoutedEventArgs.OriginalSource property:
Source adjustment by various elements and content models varies from class to class. Each class that adjusts event sources attempts to anticipate which source is the most useful to report for most input scenarios and the scenarios for which the class is intended, and then sets that source as the Source. If this source is not the one that has relevance to your handling of the event, try checking OriginalSource instead to see if it reports a different source that is more suitable.
Which is exactly what the UserControl class does, it patches the Source property in its AdjustBranchSource() method.
So, as hinted by the quoted text, you are perhaps looking for the OriginalSource property to make the code behave similarly, you'll get a reference to the Rectangle in both cases.
In my application, when a user attempts to click a slider which is on the main window, while a popup control is open, the popup control steals the mouse down event.
This results in the slider not responding to the mouse down event correctly.
(it seems to get focus and move to an incorrect location)
I found that the that the "OnPreviewMouseLeftButtonDown" in the slider does not fire when popup's "StaysOpen" property is false (and the popup is open),
and does fire when its true (or when the popup is closed).
I was wondering if someone has found a solution for this issue.
I encountered these type of issues in other controls in my application in various contexts, So I would prefer a more general solution rather than just solving this for the slider.
Sample code:
<Window x:Class="SampleApplication.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Name="Root"
Title="MainWindow" Height="350" Width="525">
<Grid Height="130" Width="300">
<Button Width="40" Height="40" Click="ButtonBase_OnClick" HorizontalAlignment="Left" VerticalAlignment="Top"></Button>
<Popup StaysOpen="False" IsOpen="{Binding ElementName=Root, Path=IsOpen}" Width="100" Height="100"
HorizontalAlignment="Center" VerticalAlignment="Center" Placement="Center">
<Grid Background="Black">
<TextBlock Text="hello"></TextBlock>
</Grid>
</Popup>
<Slider Width="200" IsMoveToPointEnabled="True" VerticalAlignment="Bottom"></Slider>
</Grid>
Thanks ahead,
Yotam
This happens because PreviewMouseDown (and it's derivates) (from the base class UIElement) has a default RoutingStrategy.Direct.
Direct - The routed event does not route through an element tree, but does support other routed event capabilities such as class handling, EventTrigger or EventSetter.
This is the source code of the event taken from ReferenceSource.
public static readonly RoutedEvent PreviewMouseLeftButtonDownEvent =
EventManager.RegisterRoutedEvent(
"PreviewMouseLeftButtonDown",
RoutingStrategy.Direct,
typeof(MouseButtonEventHandler),
_typeofThis);
And here is what happens in the Popup:
private void OnPreviewMouseButton(MouseButtonEventArgs e)
{
// We should only react to mouse buttons if we are in an auto close mode (where we have capture)
if (_cacheValid[(int)CacheBits.CaptureEngaged] && !StaysOpen)
{
Debug.Assert( Mouse.Captured == _popupRoot.Value, "_cacheValid[(int)CacheBits.CaptureEngaged] == true but Mouse.Captured != _popupRoot");
// If we got a mouse press/release and the mouse isn't on the popup (popup root), dismiss.
// When captured to subtree, source will be the captured element for events outside the popup.
if (_popupRoot.Value != null && e.OriginalSource == _popupRoot.Value)
{
// When we have capture we will get all mouse button up/down messages.
// We should close if the press was outside. The MouseButtonEventArgs don't tell whether we get this
// message because we have capture or if it was legit, so we have to do a hit test.
if (_popupRoot.Value.InputHitTest(e.GetPosition(_popupRoot.Value)) == null)
{
// The hit test didn't find any element; that means the click happened outside the popup.
SetCurrentValueInternal(IsOpenProperty, BooleanBoxes.FalseBox);
}
}
}
}
So it was designed to work this way, and you should likely not use OnPreviewMouseDown for whatever you are trying to accomplish here.
In my application, when a user attempts to click a slider which is on the main window, while a popup control is open, the popup control steals the mouse down event
While your description is not completely correct, that is the normal behaviour of any Popup control. The reason that this occurs is because the Popup control has focus and so it is listening out for the Click event even if it occurs outside the bounds of the Popup. Think about this logically now... if it didn't do this, how would it know when to close? You will find the same behaviour from the Popup control used in a ComboBox.
There is a workaround to achieve the behavior you require, Set 'IsHitTestVisible = True' for the Slider control you are use.
PS:
Set IsHitTestVisible = True, only when the Popup is Open - False otherwise.
Consider the following XAML:
<Window x:Class="ContextMenuEvent.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525" ContextMenuOpening="Window_ContextMenuOpening">
<Grid>
<Button>Ok</Button>
</Grid>
</Window>
Right-clicking the button causes ContextMenuOpening to fire, even though no context menu actually appearing.
Why is it happening? What can I do to get an even only when a context menu is REALLY opening?
I am aware I can use ContextMenu.Opened event, but this will only cover a single context menu, and I want to cover all the (existing) context menus in the form.
Not so sure why you'd use this approach. You can however easily check if a context menu would appear. Like this:
private void Window_ContextMenuOpening(object sender, ContextMenuEventArgs e) {
var menu = (e.Source as FrameworkElement).ContextMenu;
if (menu != null) {
// etc..
}
}
You would the source element of the ContextMenuEventArgs parameter, and cast it as a System.Windows.Controls.Control (or something as generic as that which would cover all clicks). You can then check the ContextMenu property.