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.
When EventBinding is used in XAML to bind commands to events of Window or RadRibbonWindow (as it inherits Window), InvalidOperationException is thrown in design-time. Workarounds: 1. Attach an event handler directly to the events of the Window (RadRibbonWindow) 2. (more MVVM-friendly) use Behavior to attach the appropriate event handler.
When creating a Word plug-in project for example, after showing a RadWindow instance moving that window by dragging it causes NullReferenceException. Available in LIB version 2016.1.222, it will be also available in the 2016 Q2 Release.
If RadWindow has its Width set to a value greater that 50% of the screen and that window is snapped to the left or right, performing minimize and then restore leads to incorrect normal size . Available in LIB version 2015.3.1123, it will be also available in the 2016 Q1 release.
This happens when RadWindowInteropHelper.AllowTransparency is set to False and RadWindow is implemented as UserControl. The Window need to be maximized firstly on the main screen and then on the secondary in order for issue to be reproduced. The issue also affects the ToolWindow that RadDocking uses for its floating Pane. In order to reproduce the problem, the primary monitor needs to have its DPI higher than the secondary one.
It happens when IsRestrictedWhenMaximized set to true.
1) Open WPF Demos and maximize it 2) Open "Alert, Prompt and Confirm" sample 3) Click "Confirm" 4) Minimize all windows (for example, by using Win+D) 5) Switch to WPF Demos again 6) Now you can't do anithing with the window, even close it. You can use task manager to close it.
Setting the Owner property to null in order to detach the minimize behavior of linked RadWindow instance to its owner does not take effect unless the RadWindow instance is closed and reopened. Available with the R3 2016 SP1 release.
Available in LIB version 2015.3.1130, it will be also available in the 2016 Q1 Release.
Available in the 2015 Q3 Release.
If you have set SizeToContent of RadWindow to true and you use one of the following options, SizeToContent will not work. - UseLayoutRounding = true - TextOptions.SetTextFormattingMode(dialog, TextFormattingMode.Display); Available in the 2015 Q3 Release.