I'm currently working on a WPF application which will run on Windows 8.1 tablet and I don't find any posts about the following issue :
My application needs to be full screen, so, I set for my views :
WindowState="Maximized"
WindowStyle="ToolWindow"
All right - my application will be displayed in full screen mode:
But, if I rotate the tablet a space is allocated and the application is not in full screen.
I don't want this scenario to happen, the application should stay always in full screen.
I tried to listen SystemEvents.DisplaySettingsChanged event and manually set full screen:
SystemEvents.DisplaySettingsChanged += Current_SizeChanged;
private void Current_SizeChanged(object sender, EventArgs eventArgs)
{
this.WindowStyle = WindowStyle.None;
this.ResizeMode = ResizeMode.NoResize;
this.WindowState = WindowState.Maximized;
this.UpdateLayout();
}
As you can see, i tried even to update layout, but still, not working!
What is strange, is the fact that if you start the application in any position but not in the normal one, it will work. For ex: if the application is started in portrait mode, rotation will not change the dimensions of the window, but if you run the application starting from landscape mode... the bug appears.
You can debug this issue using Ctrl + Alt + Arrows.
Any suggestions?
Edit: It seems that the problem is caused by keyboard. The reserved zone is for keyboard, but i don't find a way to resize to full screen. Actual width, Width and Desired Width are all the same...
Edit2: This bug can be reproduced only on Windows 8.1
You can use DisplaySettingsChanged event of the SystemEvents class. Here is an example -> How to Detect Screen Rotation
Use a property in viewmodel which will set in the Current_SizeChanged method. Then put a data trigger on this boolean and apply RotateTransform 90deg to your LayoutTransform.
A workaraund for this bug is to listen to DisplaySettingsChanged and manually set windows state to normal and after windows state to maximized, like below :
SystemEvents.DisplaySettingsChanged += Current_SizeChanged;
private void Current_SizeChanged(object sender, EventArgs eventArgs)
{
this.WindowState = WindowState.Normal;
this.WindowState = WindowState.Maximized;
}
This is caused by :
WindowStyle="ToolWindow"
Hope microsoft will solve this bug (I submitted the bug on WPF threads on MSDN). Thank you for your help!
Related
I have an issue with Winforms and touch inputs via a Microsoft Surface tablet. I know that winforms does not support touch input, but maybe there is something there can be done about this. So in my Winforms application i have a Form with two controls. A simple List Box and CefSharp ChromiumWebBrowser Control.
When I open the application the HTML is loaded and everything works fine with normal mouse input. I can click the textboxes and I can type. But when i do the same thing with touch controls on a MS Surface it seems the the ChromiumWebBrowser Control dows not get focus. The HTML Textboxes inside the Browser have focus, but the ChromiumWebBrowser Control does not. So whem i type, no input is send to the textboxes.
I tried to set focus manually whit C# in winforms, but those click events do not get fired in touch mode except for the Enter event. But this is fired only once. So i dont know how to get around this.
The user needs to be able to click outside the Browser Controle and do something there and then get back to the Browser and type into those textboxes.
Maybe someone had a similar issue and knows a workaround. If other Info is needed, please tell me.
Here is a gif to illustrate, hope it helps: https://i.stack.imgur.com/8J0EZ.gif
Thanks
private void Form1_Load(object sender, EventArgs e)
{
var asForm = System.Windows.Automation.AutomationElement.FromHandle(this.Handle);
wbMap = initBrowser();
this.panel1.Enabled = true;
this.panel1.Controls.Add(wbMap);
wbMap.FrameLoadEnd += WbMap_FrameLoadEnd;
wbMap.Click += WbMap_Click;
wbMap.Enter += WbMap_Enter;
wbMap.MouseClick += WbMap_MouseClick;
wbMap.DoubleClick += WbMap_DoubleClick;
wbMap.Leave += WbMap_Leave;
wbMap.LostFocus += WbMap_LostFocus;
wbMap.GotFocus += WbMap_GotFocus;
wbMap.PreviewKeyDown += WbMap_PreviewKeyDown;
}
private ChromiumWebBrowser initBrowser()
{
ChromiumWebBrowser wbMap = new ChromiumWebBrowser();
BrowserSettings browserSettings = new BrowserSettings();
browserSettings.FileAccessFromFileUrls = CefState.Enabled;
browserSettings.UniversalAccessFromFileUrls = CefState.Enabled;
wbMap.BrowserSettings = browserSettings;
wbMap.LoadHtml("<!DOCTYPE html><html lang=\"en\" xmlns=\"http://www.w3.org/1999/xhtml\"><head><meta charset=\"utf-8\" /><title></title></head><body><input type=\"text\"><input /></body></html>");
wbMap.Dock = DockStyle.Fill;
return wbMap;
}
private void WbMap_FrameLoadEnd(object sender, FrameLoadEndEventArgs e)
{
Console.WriteLine("QGIS_WbMap_FrameLoadEnd");
}
So i'am working with tabControl in windows forms application and i want to make the tabs get full width regardless whether the application window is maximized or not.
When the window isn't maximized everything appears great:
But when the window gets maximized the tabs doesn't get the full width:
Is there any known way to fix this problem?
Thanks in advance
You can achieve this in some way by modifying the ItemSize property as described bellow, else you'd have to draw the tab page selectors yourself.
public Form1()
{
InitializeComponent();
tabControl1.SizeMode = TabSizeMode.Fixed;
tabControl1.ItemSize = new Size((tabControl1.Width / tabControl1.TabPages.Count) - 1, tabControl1.ItemSize.Height);
}
//Hook to form or parent container Resize event, either Resize or ResizeEnd.
private void Form1_ResizeEnd(object sender, EventArgs e)
{
tabControl1.ItemSize = new Size((tabControl1.Width / tabControl1.TabPages.Count) - 1, tabControl1.ItemSize.Height);
}
I have some RoutedCommands for commands like control-A, copy paste and they all work fine.
Then I added 4 more routedcommands to move object up down left and right in the canvas using arrowkeys, they sometimes works and sometime doesn't. At first I thought it was a Focus issue on the Canvas but I just found out that at the same time, all the other routedcommands like control-A works but arrowkeys doesn't.
I really have no idea what's going on here, they are identical routedcommands with different variable names, how come one works 100% of time and one only work 50% of time?
Working RoutedCommand:
_bindings.Add(new CommandBinding(DesignerCanvas.SelectAll, SelectAll_Executed));
SelectAll.InputGestures.Add(new KeyGesture(Key.A, ModifierKeys.Control));
private void SelectAll_Executed(object sender, ExecutedRoutedEventArgs e)
{
SelectionService.SelectAll();
}
Malfunctioning RoutedCommand:
_bindings.Add(new CommandBinding(DesignerCanvas.MoveDown, MoveDown_Executed));
MoveDown.InputGestures.Add(new KeyGesture(Key.Down));
private void MoveDown_Executed(object sender, ExecutedRoutedEventArgs e)
{
e.Handled = true;
var selectedItems = from item in SelectionService.CurrentSelection.OfType<DesignerItem>()
select item;
if (selectedItems.Count() > 0)
{
for (int i = 0; i < selectedItems.Count(); i++)
selectedItems.ElementAt(i).Top += Option.OptionSingleton.Sensitivity;
}
}
The malfunctioning RoutedCommand is just not firing sometimes, especially after I open some other window and come back to the canvas, then it will stop firing while other routedcommands are unaffected. Any ideas what's causing this weird behavior?
You can sometiems use very inclusive class event handlers to trace the route of an event:
EventManager.RegisterClassHandler(typeof(FrameworkElement), CommandManager.CanExecuteEvent,
new CanExecuteRoutedEventHandler((s, e) => Debug.WriteLine("CanExecute: " + s)), true);
EventManager.RegisterClassHandler(typeof(FrameworkElement), CommandManager.ExecutedEvent,
new CanExecuteRoutedEventHandler((s, e) => Debug.WriteLine("Executed:" + s)), true);
EventManager.RegisterClassHandler(typeof(FrameworkElement), CommandManager.ExecutedEvent,
new CanExecuteRoutedEventHandler((s, e) => Debug.WriteLine("KeyDown:" + s)), true);
In your case the KeyDown may be handled before it reaches the command binding or the CanExecute event may not reach it for some other reason.
Hopefully this will help you debug the problem
This may be due to the fact that the key you are using is the "Down" key. I suspect that if you used a different key, it would work.
Some controls consume the arrow keys and pageup/pagedown keys. For example, TextBox does this. If your Canvas is in a scrollviewer, the scrollviewer might be eating it.
There are two workarounds for this:
Add a binding to the control that is eating the key gesture.
Handle KeyPreview for the Canvas (or any parent of the control that is eating the keystroke) and execute the command from there.
The answer to this question shows how you can do #2 without writing specific code in the KeyPreview handler for each command.
It turns out that it was a focus issue, I just set the focus to the canvas whenever mouse enters, now it's sort of fixed. Thanks everybody for answering.
I want to figure out a way in my silverlight application to set the PageSize on my DataPager based on the maximized size of the window so that the scrollbars do not show when maximized. Any ideas?
Here is how I wound up doing it:
using System.Windows.Browser;
void View_Loaded(object sender, RoutedEventArgs e)
{
Int32 intRowHeight = 30;
Int32 intTopOfFirstRow = 240;
pgrData.PageSize = ((Int32.Parse(HtmlPage.Window.Eval("screen.height").ToString())) - intTopOfFirstRow) / intRowHeight;
.
.
.
Here is a post about checking in JavaScript if the Window is maximized. If you're running in browser, you should be able to call something like this from Silverlight.
http://www.codingforums.com/archive/index.php/t-127058.html
This page succinctly explains how to do it.
Hope this helps.
I put several ComboBoxes on a XAML window. When I expand any of them, the DropDown part appears on the upper left corner of the screen.
I use Visual Studio 2008 C# Express. I don't remember this phenomenon when I used Visual Studio 2008 (Trial Version), though I use the same FrameWork (3.5).
It seems to be a bug.
Workaround:
Use Window.Show() instead with a custom logic to simulate the ShowDialog() behavior.
This appears to be a bug in WPF. In my case, I was trying to open a window in the Loaded event of another window. To get around this, I set a timer up to fire, then used a delegate to open the window (cannot open the window in a timer event because the calling thread that opens a window must be STA).
Edit - timer isn't necessary - didn't see the answer above just queue it on the dispatcher...
private delegate void DelegateOpenWindow();
private DelegateOpenWindow m_DelegateOpenWindow;
private Timer loginTimer = new Timer(200);
private void MainWindow1_Loaded(object sender, RoutedEventArgs e)
{
// create delegate used for asynchronous call
m_DelegateOpenWindow= new DelegateOpenWindow(this.OpenWindow);
// start a timer to fire off the open window.
loginTimer.Elapsed += loginTimer_Elapsed;
loginTimer.Enabled = true;
}
void loginTimer_Elapsed(object sender, ElapsedEventArgs e)
{
loginTimer.Enabled = false;
this.Dispatcher.BeginInvoke(m_DelegateOpenWindow);
}
void OpenWindow()
{
MyWindow w = new MyWindow();
w.Owner = this;
w.ShowDialog();
}
I started observing this (and other strange behavioral quirks) yesterday when I tried to "tweak" window sizes, shapes, colors, and invoke a log-on dialog from the Window.Loaded event handler. I had been doing this just fine in each of a dozen+ individual "MVVM" pattern apps. Yesterday, I decided to move this from each app's code behind into a consolidated code-behind base class, since the pre-processing had become common in all those apps. When I did, the drop-downs in two ComboBoxes in the log-in dialog suddenly appeared in the upper left corner of my screen. I seem to have "solved" it by using the following technique (your mileage may vary):
protected void WindowBaseLoadedHandler(object sender, RoutedEventArgs e)
{
...non-essential lines of code removed...
if (DataContext != null)
{
Dispatcher.BeginInvoke(DispatcherPriority.Normal, new Action(() =>
{
/*----------------------------------------------------------------------
* Do we have a View Model? If so, perform standard VM Initialization...
*---------------------------------------------------------------------*/
this.IsEnabled = false;
LoginDlg loginDlg = new LoginDlg();
loginDlg.ShowDialog();
if (!loginDlg.Success)
{
/*-----------------------------------
* Log on failed -- terminate app...
*----------------------------------*/
...termination logic removed...
}
this.IsEnabled = true;
}));
}
WindowBaseLoadedHandler is the Loaded event handler. LoginDlg is a WPF app with a dialog containing two ComboBoxes.
Recap: After I consolidated the code into the Loaded event handler of the base class the ComboBox's drop down lists appeared in the upper left corner of my screen. Once I wrapped the logic into the Dispatcher.BeginInvoke call, the appropriate ComboBox behavior returned with lists below the current item.
I suspect WPF needs the application to return from the Loaded event to complete the layout system's initialization. That doesn't fully explain why it worked before, but I'll have to queue up my desire to hunt that "why" down for some rainy day in the future and celebrate overcoming the latest obstacle for today.
In any event, I hope someone finds this of use.
I'm using the latest .Net 4.5 and WPF framework and I still have this problem. One thing I noticed is that it only happen when there's an attached debugger. When the debugger is not attached, everything works fine.
I had the same problem on Visual Studio 2019.
Using window.Show() can help but it can ruin your design.
The solution is to open the window asynchronously.
var yourDialog= new YourDialog();
yourDialog.Owner = this;
TaskCompletionSource<bool?> completion = new TaskCompletionSource<bool?>();
this.Dispatcher.BeginInvoke(new Action(() =>
completion.SetResult(yourDialog.ShowDialog())));
bool? result = await completion.Task;
You can also create a more elegant solution by making the extension method:
public static class AsyncWindowExtension
{
public static Task<bool?> ShowDialogAsync(this Window self)
{
if (self == null) throw new ArgumentNullException("self");
TaskCompletionSource<bool?> completion = new TaskCompletionSource<bool?>();
self.Dispatcher.BeginInvoke(new Action(() => completion.SetResult(self.ShowDialog())));
return completion.Task;
}
}
And you can use it like this:
await dlgReview.ShowDialogAsync();
It’s a bug in WPF (not the only one, I'm afraid). It happened when I opened another window in the Loaded Event, something like:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
Window selectionWindow = new SelectionWindow();
bool? result = selectionWindow.ShowDialog();
if (result == true)
RecordChanged();
}
I already found a workabout.