PreviewClosed event is called twice when using custom close button in DialogWindow

There should be an easy method to add/override the shadow of a RadWindow. Either via XAML attributes or code behind.

<telerik:RadWindow x:Class="MyRadWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"
        Header="Settings" WindowStartupLocation="CenterOwner" SizeToContent="True" ResizeMode="NoResize" MinWidth="500" MaxWidth="900"    DropShadowOverride="True" DropShadowOverrideBlurRadius="10" DropShadowOverrideDirection"-90", DropShadowOverrideDepth="3" DropShadowOverrideColor="White">
     
    <Grid>
 
    <!-- UI code -->
 
    </Grid>
 
</telerik:RadWindow>

As an example Windows 10 OS Window gets different Opacity for its Title and Buttons when Inactive (open two Window-s and make them appear one behind the other -- the one in the background of the active window is inactive). Our Office2016 and Office2016 Touch themes are inspired by Windows 10 OS as we officially stated so we might mind adding this visual appearance on our side for RadWindow.

The property is present, but it is not implemented. 

Hello,

I've found a new bug regarding per-monitor DPI awareness in the latest WPF controls build (2020.1.115).

Applications start fine on the modern Windows 10 systems (1607 or later) but crash on previous Windows versions.

The conditions to reproduce:

• The application is launched on Windows version older than Windows 10 1607/Windows Server 2016. I've reproduced it on Windows 8.1/Windows Server 2012 R2, but I suppose it also affects Windows 10 1507/1511, and probably Windows 8/Windows Server 2012.
• Application manifest contains:

<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/PM</dpiAware>

Here is the stack trace:

System.EntryPointNotFoundException: Unable to find an entry point named 'GetDpiForSystem' in DLL 'User32.dll'.

   at Telerik.Windows.Controls.InternalWindow.Standard.NativeMethods.GetDpiForSystem()

   at Telerik.Windows.Controls.InternalWindow.Standard.DpiHelper.GetSystemScaleFactor()

   at Telerik.Windows.Controls.InternalWindow.Standard.DpiHelper.CalculateScaleFactor(IntPtr hwnd)

   at Telerik.Windows.Controls.InternalWindow.Standard.DpiHelper.GetPerMonitorDPIAwareScaleFactor(IntPtr hwnd)

   at Telerik.Windows.Controls.InternalWindow.ChromelessWindowHelper.<Initialize>b__81_0(Object sender, EventArgs args)

   at System.Windows.Window.OnSourceInitialized(EventArgs e)

   at System.Windows.Window.CreateSourceWindow(Boolean duringShow)

   at System.Windows.Window.CreateSourceWindowDuringShow()

   at System.Windows.Window.SafeCreateWindowDuringShow()

   at System.Windows.Window.ShowHelper(Object booleanBox)

   at System.Windows.Window.Show()

   at Telerik.Windows.Controls.InternalWindow.WindowWithNoChromeWindowHost.Open(Boolean isModal)

   at Telerik.Windows.Controls.WindowBase.ShowWindow(Boolean isModal)

   at Telerik.Windows.Controls.RadWindow.Show()

   at TelerikWpfCrash.App.OnStartup(StartupEventArgs e) in C:\Users\fedarovich\source\repos\Test\TelerikWpfCrash\TelerikWpfCrash\App.xaml.cs:line 20

The issue happens because the code calls the WinAPI functions not available on these OS versions (for example, GetDpiForSystem, but maybe there are more). 

I've attached a small example to reproduce this issue. It is for .Net Core 3.1, but the same issue exists in .Net Framework too.

Hi,

   There is a bug in version 2019.3.1023.45 RadWindow when I minimum and restore window from task bar

When creating themed applications using RadControls, the standard Windows MessageBox control looks out of place.  With that in mind, the predefined RadWindows (Alert and Confirm) seem to be natural replacements for a typical MessageBox.  

However, when these dialogs open, they are silent  That is, they don't play any error, warning, or question sounds like the standard MessageBox - which makes them seem "strange" when used as a replacement.

Adding sounds to (for instance) the Alert window is fairly simple and can be accomplished like this:

RadWindow.Alert(new DialogParameters()
{
    Content = new System.Windows.Controls.TextBlock {
        Text = ex.Message, Width = 250, TextWrapping = TextWrapping.Wrap },
    Header = "Update Error",
    Opened = (alertDialog, eventArgs) => System.Media.SystemSounds.Exclamation.Play()
});

Though, it'd be nice if the ability to play a sound was built-in.  I'd suggest that the DialogParameters class used to customize the predefined dialogs be extended to support a SystemSound member of type System.Media.SystemSounds which, if defined, would play the specified sound when the dialog opens.

After fixing this BUG (Release LIB 2019.3.930), an additional issue is found.

A window is in Maximized or Normal state, click on the application icon in the taskbar to minimize it and click again to restore the window. It gets clipped to ~160*26 pixels. After clicking on this header, it gets restored to Maximized or Normal state depending on the initial state.

I have a two-monitor setup with identical resolutions (FullHD on both monitors) and Scale is 100% on both monitors.

Initial BUG was fixed in recent update.

One issue still exists:

When minimizing a window that is maximized in the way the intial issue described the problem, and you reactivate it by clicking on its "TaskBarIcon", the window gets clipped incorrectly again.

This is reproducible when you disable the automation peers by setting the AutomationManager.AutomationMode static property to Disabled.

It happens when you open a new RadWindow dialog (using the ShowDialog method), and the close it. After this, when you interact with the main window (click a button, hover a GridView, etc.) the exception occurs.

The exception is thrown only in the Output pane of Visual Studio and it doesn't cause any harm to the application. You can safely ignore it.

The exception message is "Invalid window handle".

To work this around you can enable the "Enable Just My Code" option in Visual Studio.

Moving a window fast on low performance machine or between two monitors causes incorrect offset to be applied to the mouse cursor