In Windows 10, when using touch device like Surface, touching an input control like a TextBox in a not maximized window, causes moving the whole window up, so that the user can see what he is typing (if keyboard is docked). But it does not happen when WindowStyle is set to none. Why it does not happen? We need this behavior in our app. Can it be fixed on WindowStyle=None? I found it's not connected with it's style - there are no build in triggers or something. We need WindowsStyle=None for custom close button bar (we want the bar to be transparent, only the button is visible).
I faced a similar issue trying to get my application to react to the presence of the Windows 10 touch keyboard properly, but it wouldn't do so unless WindowStyle was set to something other than None.
Struggled with it for a while, until I decided to just try and style the Window myself and removing the borders manually, which led me to discover the WindowChrome class.
The WindowChrome documentation mentions this about WindowStyle="None":
One way to customize the appearance of a WPF application window is to set the Window.WindowStyle property to None. This removes the non-client frame from the window and leaves only the client area, to which you can apply a custom style. However, when the non-client frame is removed, you also lose the system features and behaviors that it provides, such as caption buttons and window resizing. Another side effect is that the window will cover the Windows taskbar when it is maximized. Setting WindowStyle.None enables you to create a completely custom application, but also requires that you implement custom logic in your application to emulate standard window behavior.
So it seems that because this non-client (or OS) frame is missing, it causes the application to not be able to react to the keyboards presence.
The solution is to implement a custom WindowChrome. This can be done like this:
<Window x:Class="WpfApp.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:shell="clr-namespace:System.Windows.Shell;assembly=PresentationFramework"
Title="MainWindow" Height="350" Width="525" WindowState="Maximized">
<shell:WindowChrome.WindowChrome>
<shell:WindowChrome NonClientFrameEdges="None"
UseAeroCaptionButtons="False"
CornerRadius="0"
GlassFrameThickness="0"
ResizeBorderThickness="0"
CaptionHeight="0" />
</shell:WindowChrome.WindowChrome>
<Grid Background="DarkOrange">
<TextBlock Text="TEST" VerticalAlignment="Center"
HorizontalAlignment="Center" FontSize="32" />
</Grid>
</Window>
If you absolutely must use WindowStyle="None", then according to the documentation above, the Window logic must be custom. Fortunately there's a nice example from Microsoft on how to write custom logic to react to the presence of a touch keyboard: See this link.
If you would like to add your own custom buttons to the title bar, check out this excellent post about styling your Window.
Hope this helps!
UPDATE:
After further investigation, it turned out that this solution only worked on Windows 10 version 1903. When tried on 1809 which we use in production, it didn't work. The reason is that apparently Microsoft have changed the way applications react to the touch keyboard when in full-screen mode.
This can be easily tested by maximizing Explorer in both versions of Windows, and to see how in 1809 nothing happens, but in 1903 the Window is resized to fit the remaining space on the screen.
Another important thing I noticed is that when I start the application from Visual Studio (whether debugger is attached or not), when the touch screen shows up, the UI doesn't react to it, but when I run the executable from explorer, then it does work. So in my testing I would always build, then go to bin\Debug, and start the exe from there.
Take the Grid Layout divide it into 3 rows and add the one custom button to the top right corner of row and on that button event handler do the Window closing code and same for minimizing
and Set the WindowStyle=none
Related
I created a WPF application that has an overlay mode. In this mode, the whole application gets semi transparent. I'd now like to be able to click through this window to operate with elements behind it [other program UI's, desktop icons etc.]
I wonder if there is the possibility to configure the window right away to represent this behaviour. I set up my application window like this:
WindowStyle="None" AllowsTransparency="True" Opacity="0.5" Background="Black" IsHitTestVisible="True" Focusable="True" IsTabStop="False"
If I set the Background to x:Null or Transparent, I can click through the application. However, the application is not visible at all any more then.
If this is not possible directly, I thought about another solution:
When clicking on the Application, minimize it, execute another mouse click, and then maximize the application. I found some example code for a global mouse click which looks like this:
MouseEventArgs e = new MouseEventArgs(Mouse.PrimaryDevice, 0);
e.RoutedEvent = Mouse.MouseEnterEvent;
youUIElement.RaiseEvent(e);
// Or
InputManager.Current.ProcessInput(e);
However, I think this will not work when trying to do double-clicks.
So, general desire in a few words:
Semi-transparent WPF application, always on top, click-through. Also Keyboard input should pass through.
I set up a special hotkey that brings the application back.
Any helps / ideas?
I'm trying to create a simple 'dialog'-type window in WPF. However, for this specific instance, I do not want the client area to have a border, or even a background for that matter. I just want my controls to appear over the background of the window the way they do with a simple MessageBox.
I played with the different values for WindowStyle but they all called out the client area with a color. I also tried simply setting the client's Background to transparent, but that didn't work either just rendering it in black.
Here's a crappy Photoshop job showing what I'm after:
Note: I'm not after the messagebox contents themselves--e.g. the icon, buttons and message, etc.--I'm only asking about how to suppress the client area from appearing in any window. I just happened to use a messagebox as an example as someone linked to it in their answer.
As you can see (or rather can't) there is no visible demarcation of the client area.
Used to be so simple in WinForms, but WPF has me stumped. Anyone?
I'm not sure what you're after. Do you want only the controls on your dialog to be visible with the dialog's border and background transparent? If so, try these settings on your dialog:
WindowStyle="None"
ShowInTaskbar="False"
AllowsTransparency="True"
Background="Transparent"
If you want your dialog's background color to the Winform System.Control with no border, set your form's Background like this (instead of Transparent):
Background="{DynamicResource {x:Static SystemColors.ControlBrushKey}}"
(I am trying to learn WPF using tutorials and documentation, and trying to develop a user interface for my backend-complete application while I do say. I've heard people say that the learning curve is quite steep. But sometimes I wonder whether what I'm trying to do is actually something that's hard to do in WPF, or if it's simple but I'm thinking in wrong terms, or if it's neither, it's quite simple but I just happen not to know how.)
Here's my current question. I wanted clicking that clicking some part of my UI will bring up a 'popup' where the user can enter more information. I would like a 'lightbox-style' popup, i.e. the popup is modal to the page, it darkens the rest of the page to become the center of attention, etc. These are seen commonly on Web sites.
A bit of searching led me to the WPF Popup control. I added it, put my content in, set the IsOpen property to True, and -- presto! A popup. Then I added an invisible Rectangle that covers my whole window, and set it to Visible as well when I want my popup to open. Great!
So now I wanted to do this dynamically, because sometimes I will be loading a record which will sometimes have a need to open another control (a UserControl) in a popup to edit its information. So I made myself a method called OpenPopup. But I can't seem to find a way to write this method using WPF. In Windows Forms I'd have written: (I use VB.NET)
Sub ShowPopup (form as Form, ctrl as Control)
'Create 'rect' as new dark rectangle control
'Z-order it to the top
'form.Controls.Add 'rect'
'form.Controls.Add ctrl
'Z-order 'ctrl' to the top
'Center 'ctrl'
'Set focus to it
End Sub
But with WPF I run into problems:
1) I can't add it to the WPF window, because it already has a child.
2) If that child is a Canvas, that's not too bad. I can detect that, and add it to the Canvas. I have to find some way to set its Left, Top etc. properties and Width and Height, since those do not seem to be properties of the Rectangle control but rather extended by the Canvas object -- in XAML they're called Cavnas.Top etc. but Intellisense is not showing them when I try to use it in code.
3) But if it's a StackPanel? Then my rectangle will just be stacked below the other controls! And not covering them! Is there a way around this?
4) And if the window contains only one control and no container control at all?
5) I think there were more problems I ran into. But let's start with these.
Thanks in advance for your help.
1) I can't add it to the WPF window, because it already has a child.
Ah, the evils of codebehind. The solution is not to add it to the visual tree, it is to place it in the visual tree, ready and waiting to pounce, but hide it from the user's view.
Here's a sample you can drop in Kaxaml that demonstrates the point. Set the Lightbox Grid's Visibility to Hidden to access the hidden content.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Viewbox>
<TextBox Text="SIMULATING CONTENT" />
</Viewbox>
<Grid x:Name="Lightbox" Visibility="Visible">
<Rectangle Fill="Black" Opacity=".5"/>
<Border
Margin="100"
Background="white"
BorderBrush="CornflowerBlue"
BorderThickness="4"
CornerRadius="20">
<Viewbox Margin="25">
<TextBox Text="SIMULATING LIGHTBOX"/>
</Viewbox>
</Border>
</Grid>
</Grid>
</Page>
2) (snip) Intellisense is not showing them when I try to use it in code.
Canvas.Top etal are Attached Properties. Attached Properties are extremely convenient and easy to use in XAML, but they are very confusing and hard to use from code. Another reason why codebehind is evil.
3) But if it's a StackPanel? Then my rectangle will just be stacked below the other controls! And not covering them! Is there a way around this?
I redirect you back to 1. There are also many other container controls in WPF. You should investigate them and observe how they control layout. For instance, my use of the Grid was not to make use of its ability to block off sections of UI for controls, but for its ability to layer controls ontop of each other and to stretch them out to their maximum available size for the available space (the viewboxes are just there to zoom the controls instead of stretch them).
4) And if the window contains only one control and no container control at all?
The root of a window would almost always be a container control. But you control that, so if you needed to add controls to the visual tree at runtime you could easily ensure the child of the window is a container control you could deal with.
5) I think there were more problems I ran into. But let's start with these.
No kidding. My number one suggestion for people in your situation is to drop what you're doing and learn about MVVM. The Model-View-ViewModel is a very simple way to code WPF applications that takes advantage of many of the features of WPF--databinding, templating, commands, etc. It allows you to code your logic not in codebehind (RETCH) but in easy to create and test classes.
I met a problem regarding to WPF window on windows vista SP2.
I create a window with following properties:
WindowStyle="None"
ShowInTaskbar="False"
ResizeMode="NoResize"
Background="Transparent"
The ShowInTaskbar is set to false, which means the window will not show taskbar button, but you can see it in the taskbarlist using Alt+tab
In my application, when receiving some events, the window will be created and Show(), for example,
window1 wd = new windw1();
wd.topmost = true;
wd.show();
I happen to find in the followin case, the window is not show correctly
My display setting in the power manager is set to turn off display in 1 minute,
After 1 minute, my display turned off, after that, there is a event which triggered the window to show, but after i move the mouse to get the display back, i didn't see the window is showed, instead, when i use Alt+Tab, i can find a window transparent in the taskbarlist with my application icon. It's very strange. after i click "show desktop" for two times, the window show itself.
i googled in the internet, and found it seems that when showtaskbar is set to false, there will be another transparent window created which is the owner for the current window, this explains that why i can see transparent window in taskbarlist usring Alt+Tab. I assume that the window is not correctly painted in this case.
I think it's a bug of WPF, is there any workaround for it?
Thanks in advance
you can make your application power aware and make it check the monitor's state. Please refer to http://msdn.microsoft.com/en-us/library/ms703398%28VS.85%29.aspx.
You can then subscribe to the Powerbroadcasts and get informed, when the monitor is turned back on.
On that event, you could force your application to redraw the window in question.
Sadly this is only a workaround and no fix to the initial problem
I want to create a WPF window that behaves as a modal dialogue box while at the same time facilitating selected operations on certain other windows of the same application. An example of this behaviour can be seen in Adobe Photoshop, which offers several dialogues that allow the user to use an eyedropper tool to make selections from an image while disabling virtually all other application features.
I'm guessing that the way forward is to create a non-modal, always-on-top dialogue and programmatically disable those application features that are not applicable to the dialogue. Is there an easy way to achieve this in WPF? Or perhaps there's a design pattern I could adopt.
Yes, there is the traditional approach you describe where you programmatically enable/disable features, but WPF also opens up several new possiblities that were really not possible in WinForms and older technologies.
I will explain four WPF-specific ways to do this:
You can secretly and automatically replace a window's contents with a picture of its contents using a Rectangle with a VisualBrush, thereby effectively disabling it. To the user it will look as if the window is unchanged, but the actual contents will be there underneath the picture, so you can use it for hit-testing and even forward selected events to it.
You can add a MergedDictionary to your window's ResourceDictionary that causes all TextBoxes to become TextBlocks, all Buttons to become disabled, etc, except as explicitly overridden using custom attached properties. So instead of looping through all your UI selectively enabling/disabling, you simply add or remove an object from the MergedDictionaries collection.
You can use the InputManager to programmatically generate and process real mouse events in particular parts of a disabled window, disallowing any mouse events that don't hit-test to something "approved."
Use data binding and styles to enable/disable individual controls rather than iterating through them
Details on replacing window with picture of window
For this solution, iterate your app windows and replace each content with a Grid containing the original Content and a Rectangle, like this:
<Window ...>
<Grid>
<ContentPresenter x:Name="OriginalContent" />
<Rectangle>
<Rectangle.Fill>
<VisualBrush Visual="{Binding ElementName=OriginalContent}" />
</Rectangle.Fill>
</Rectangle>
</Grid>
</Window>
This can be done programmatically or by using a template on the Window, but my preference is to create a custom control and create the above structure using its template. If this is done, you can code your windows as simply this:
<Window ...>
<my:SelectiveDisabler>
<Grid x:Name="LayoutRoot"> ... </Grid> <!-- Original content -->
</my:SelectiveDisabler>
</Window>
By adding mouse event handlers to the Rectangle and calling VisualTreeHelper.HitTest on the ContentPresenter to determine what object was clicked in the original content. From this point you can choose to ignore the mouse event, forward it to the original content for processing, or in the case of an eyedropper control or an object selection feature, simply extract the desired objects/information.
Details on MergedDictionary approach
Obviously you can restyle your whole UI using a ResourceDictionary merged into your window's resources.
A naiive way to do this is to simply create implicit styles in the merged ResourceDictionary to make all TextBoxes appear as TextBlocks, all Buttons appear as Borders, etc. This does not work very well because any TextBox with its own style or ControlTemplate explicitly set may miss the updates. In addition, you may not get all objects as desired, and there is no way to easily remove the Commands or Click events from buttons because they are explicitly specified and the style won't override that.
A better way to work this is to have the styles in the merged ResourceDictionary set an attached property, then use code-behind in the PropertyChangedCallback to update the properties you really want to change. Your attached "ModalMode" property, if set to true, would save all the local values and bindings for a number of properties (Template, Command, Click, IsEnabled, etc) in a private DependencyProperty on the object, then overwrite these with standard values. For example a button's Command property would be set to null temporarily. When the attached "ModalMode" property goes false, all the original local values and bindings are copied back from the temporary storage and the temporary storage is cleared.
This method provides a convenient way to selectively enable/disable portions of your UI by simply adding another attached property "IgnoreModalMode". You can manually set this to True on any UIElements that you don't want the ModalMode changes to apply to. Your ModalMode PropertyChangedCallback then checks this and if is true, it does nothing.
Details on InputManager approach
If you capture the mouse, you can get mouse coordinates no matter where it is moved. Translate these to screen coordinates using CompositionTarget.TransformToDevice(), then use CompositionTarget.TransformFromDevice() on each candidate window. If the mouse coordinates are in bounds, hit-test the disabled window (this can still be done even when a window is disabled), and if you like the object the user clicked on, use InputManager.ProcesInput to cause the mouse event to be processed in the other window exactly as if it was not disabled.
Details on using data binding
You can use a styles to bind the IsEnabled property of Buttons, MenuItems, etc to a static value like this:
<Setter Property="IsEnabled" Value="{Binding NonModal, Source={x:Static local:ModalModeTracker.Instance}}" />
Now by default all items with these styles will automatically disable when your NonModal property goes false. However any individual control can override with IsEnabled="true" to stay enabled even in your modal mode. More complex bindings can be done with MultiBinding and EDF ExpressionBinding to set whatever rules you want.
None of these approaches require iterating through your visual interface, enabling and disabling functionality. Which of these you actually select is a matter of what functionality you actually want to provide during modal mode, and how the rest of your UI is designed.
In any case, WPF makes this much easier than it was in WinForms days. Don't you just love WPF's power?
What you're looking for is similar to a Multiple Document Interface. This isn't available by default in WPF but there are some efforts out there to support this, both free and commercial.
It will be up to you to identify the current state of the application and enable/disable UI elements in response to this.
I think an always-on-top windows that programmatically disables certain app features is the way to do this. It might be easier to keep a "white list" of features that can be enabled while this form is open, and then disable everything that isn't on the list (as opposed to trying to maintain a "black list" of everything that can't be enabled).
I believe the best approach to solve this is using the InputManager approach mentioned previously. This design pattern allows you to connect commands to your toolbar buttons/menu items etc and each will call a CanExecute handler you specify for your command. In this handler, you would set the command to not enable if your always-on-top non-modal window was open.
http://msdn.microsoft.com/en-us/library/ms752308.aspx