Consider a scenario with two Windows. The first one is centered. Users open a second Window from the first one, and the second Window gains focus.
At this point, if the user clicks on the titlebar of the first Window, it will lose its centered position and move to the corner of the screen.
Here is a REPL test page: https://blazorrepl.telerik.com/wSOMEtEL55Ddk4v441
A possible workaround is to set explicit Width, Height, Top and Left values to the first Window, so that it's not centered, but appears to be: https://blazorrepl.telerik.com/QeaWuNus07TfnCz731
We are using a "TelerikWindow" that does neither contain the "WindowAction" "Minimize" nor "Maximize", since we do not want the user to do so. It is still possible, however, to minimize / maximize the window using the keyboard shortcuts described here: https://demos.telerik.com/blazor-ui/window/keyboard-navigation
We came up with a hack to work around the current behaivor:
Dear team,
we use a BlazoredTypeahead control inside a TelerikWindow and have this problem.
When you open the result dropdown of BlazoredTypeahead and click on the scrollbar in the result dropdown, the result dropdown is closed suddenly.
This only happens when a BlazoredTypeahead control is inside a TelerikWindow. If I remove the Telerik Window everything works as expected.
Attached is a running example, which demonstrates the issue. In the example just click on the "New" button in the grid, this will open the TelerikWindow, which contains the BlazoredTypeahead control.
Thanks for your help.
Window border styling via css has no effect - no border shows at all - I don't need help, just reporting. Tried it on Edge, Chrome and Firefox
.MyClass { /* targets the entire popup element */
Microsoft Visual Studio Community 2019 Version 16.9.2
border: 5px solid red; }
ProgressĀ® TelerikĀ® UI for Blazor Extension - 2021.1.218.1
.NET Framework 4.8.04084
Scenario is a page containing a grid component and a child component based on the TelerikWindow for viewing/adding/editing. Record selection in grid makes child component visible. Full-record editing may exceed available display space. I have already broken down the model form into smaller pieces using tabstrips but some of the remaining pieces cannot be logically broken up much further.
I would like for optional (or automatic) creation of vertical and horizontal scroll bars on the window when the content exceeds the size of the editing window.
Currently, oversize content is off-screen and not reachable.
If I have a grid inside a TelerikWindow, when I show the window allowing it to be draggable, there seems to be undesired behavior. In my environments, with 2.26.0, the TelerikWindow extends to the right of the screen and the draggable operation is impacted. I have the following code (very cut-down and simplified) as my Index.razor. If you click the button and start dragging the window around you should see what I am referring to.
@page "/"
The window in modal mode, if opened and then maximized, then closed while still maximized, on open again the window is restored to initial unmaxmized state however the button is still in "unmaximize" state so you need to click it twice to maximize again.
Setting the state to ImageViewWindow.Maximized = false; before reopening does not do anything with or without StateHasChanged();
When using an enclosing div element for Your Telerik Window component:
A view in the web console shows that the defined name in the class-attribute of the div element isn't recognized.
When setting the Hidden property to true on a WindowAction, the action button is still rendered, e.g.:
<WindowAction Name="Maximize" Hidden="true"></WindowAction>
See this REPL for an example:
https://blazorrepl.telerik.com/wPbGYMvi23qjUo1c41
The described functionality listed on https://demos.telerik.com/blazor-ui/window/stacking-windows
"The Telerik Window component for Blazor provides stacking z-index functionality that brings to front the component any time it receives focus."
doesn't appear to be working in the demo. When the one window receives focus the z-index does not change. This appears to not work correctly in the demo either.