This one has me puzzled, and I am starting to believe it's a bug in either the core winapi, or possibly in WPF. In case nobody here knows a possible cause for the problem I will file a bug report at Microsoft Connect.
The problem presents itself once I call Window.Show(), but the root cause might lie in a different place, including prior calls to user32.dll. Once I call Show() on my window, my window does show up, but another window pops up on the taskbar but doesn't become visible. Moreover, clicking it does not make that window visible.
The window I am trying to show has the following properties set, which seem to be required to cause this weird behavior. Changing any of them 'fixes' this issue.
WindowStyle="None"
WindowState="Maximized"
ShowInTaskbar="False"
I am creating a virtual desktop manager (VDM), hence I hide/show windows through user32.dll. If I don't hide any windows prior to showing my desired window, the problem doesn't present itself either. The entire code of the VDM is available on github. The specific user32 calls occur in a wrapper which can also be found on github.
// Hide windows.
var hideWindows = _windows
.Select( w => new RepositionWindowInfo( w.Info ) { Visible = false } );
WindowManager.RepositionWindows( hideWindows.ToList() );
The RepositionWindows method is a bit long to post here, but you can see it in its entirety on github. It uses BeginDeferWindowPos, DeferWindowPos and EndDeferWindowPos.
Lastly, when I show/hide my window using the Visibility property instead of using Show() and Hide() the described behavior doesn't occur in some circumstances (more on that later) either. However, according to the documentation on msdn:
Calling Show achieves the same end result as setting Visibility
property of the Window object to Visible. However, there is a
difference between the two from a timing perspective. Calling Show is
a synchronous operation that returns only after the Loaded event on
the child window has been raised [...]
This seems very much related to operations being executed synchronously or asynchronously. In some scenarios I hide one particular window using user32's ShowWindow. If immediately after I show my window (using a shortcut key) the problem occurs again, regardless of whether I use Visibility or Show() to show the window. However, if I hide the window using ShowWindowAsync(), all is fine again.
Lastly ... (so many if's ... I know, sorry) when I click on any window (select it) prior to showing my window, the problem doesn't occur either. If I wouldn't be using a shortcut key to show the window I would have never found out about this.
What could be the root cause of this problem?
I think I've identified the core issue which is causing this. When windows are hidden, another window is made active. However, it seems as if only windows present on the task bar are made active. When I hide all windows and afterwards call GetActiveWindow it indicates no window is active (return value null).
When subsequently a window is shown which shouldn't show up on the task bar (no matter whether Show() or Visibility is used) the hidden window is shown on the task bar.
A workaround which fixes this is checking after a deferred window positioning operation whether any window is active. If not, I now give focus to the task bar. Next time the non-taskbar window is shown, the bug doesn't occur!
succeeded = User32.EndDeferWindowPos( windowsPositionInfo );
if ( succeeded && User32.GetActiveWindow() == IntPtr.Zero )
{
WindowInfo startBar = GetWindows()
.Where( w => w.GetClassName() == "Shell_TrayWnd" ).FirstOrDefault();
if ( startBar != null )
{
User32.SwitchToThisWindow( startBar.Handle, false );
}
}
Related
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
I have problem with an application where modal WPF dialog occasionally goes behind the main application window. This hapens when I click button on the dialog which does some processing and updates controls (through binding) in the main application window. When it goes in background - clicking anywhere in the application brings it back into foreground.
var dialog = LoadDialogWindowThroughMEF();
dialog.Owner = Application.Current != null ? Application.Current.MainWindow : null;
dialog.ShowInTaskbar = false;
dialog.WindowStartupLocation = WindowStartupLocation.CenterOwner;
return dialog.ShowDialog();
The above code shows how I open modal window. This happens very rarely.
Does anybody know what could be the problem?
I'm not sure I have an answer for you, but I can share some of my thoughts:
Every time I've encountered this type of problem, it happened because the Owner wasn't set properly. So, I'd try to not set the Owner and see if that makes the problem reproducible. You need to be absolutely sure that Owner is set to the correct parent window at all times1. You might also want to check that it is the actual MainWindow of your application that are supposed to be the parent. I think that most of the time it is beneficial to be explicit2 in your code. In this case that means that it is better to assign the known parent (maybe you have a reference to the parent somewhere that you could use), rather than relying on the Application.Current to provide you with that reference. Doing so will put you in control of the assignment to Owner. It could even make it possible to get rid of the ?: operator since you would have the means to control the reference even during unit testing.
I also want you to make sure that the code that is actually updating the parent window doesn't in any way force focus to a specific control on the parent window, or anything like that. (As long as the correct parent is set as Owner, I don't see this as a likely problem.)
I hope this helps you, but I understand if it doesn't. The fact that your dialog reappears when you click the parent window disproves some (or all!) of my points...
1 Except when running your unit tests, but that's a completely different matter.
2 As in the first meaning of the word according to wiktionary.org/wiki/explicit, and as opposed to implicit.
I am developing a WPF-application using mvvm pattern. And a strange problem occurred to me.
There is a form, which contains a devexpress DXGrid control. There is a command binded to double click gesture in presenter. When the command triggers a new window is created and shown through factory class(the Show() method is used).
So, it happens from time to time that the whole application(all application windows) is blocked when this window is shown. This lockup disappears after i focus any other application.
For the first time this problem occurred after updating devexpress version. Then this problem occurred any time new window was shown after double click on grid row. The problem was partially fixed by setting new window`s Owner property.
Now this problem occurs from time to time. It seems as if threads are involved here, but i dont understand how. =(
p.s.:
there is one more strange thing, when new window is shown and no lockup-problem occurred, the first window is still focused and i have to click on newly shown window before i can use any controls, placed on it.
I have tried:
set ShowActivated property
call Activate() after Show()
newform.Dispatcher.CheckAccess() to
determine which thread calls Show()
method
check newform.IsActive property after
show (value = true)
Could you tell me how to fix, please?
Thank you.
Well to fix the issue of first window being focused rather than the newly shown window, you need to do the following, after calling the show method for the new window:
Mouse.Capture(null);
Hopefully the issue would be resolved.
have a TextBox item (MyTextBox) on a TabItem control. I have code that looks as follows:
MyTextBox.Focus();
Keyboard.Focus(MyTextBox);
When I run this code through the debugger I see the following after the lines are executed:
MyTextBox.IsFocused = true
MyTextBox.IsKeyboardFocused = false
Can anyone tell me why the textbox isn't receiving keyboard focus? It's just a standard TextBox control that is enabled.
When you try to set Focus to an element besides the things enumerated above by our coleague, you must also know that WPF does not allow cross threaded operations.
In some cases this exception is not raised like in the Focus method call case. What I've done to fix this issue is to call all the code that involves Keyboards focus in an action.
This action is ran inside the control dispatcher to make sure that my code is not being executed from another thread than the UI thread (e.g. timer event or an event raised from another thread):
[UIElement].Dispatcher.BeginInvoke(
new Action(
delegate{
/// put your Focus code here
}
)
);
MyTextBox.IsKeyboardFocused is false because you are looking at it under debugger and the keyboard focus is probably in your Visual Studio... Try debugging focus without breakpoints (e.g. Debug.Write or trace brakepoints) to see actual values of MyTextBox.IsKeyboardFocused in runtime.
Also notice that Focus() method returns boolean value that indicates whether focus was successfully set. Does it return False in your case? If yes, I would suggest stepping into Focus() method in order to find out what is wrong.
3 important properties must be true: IsVisible="True", Focusable="True". IsEnabled="True".
To be focusable, Focusable and IsEnabled must both be true.
http://msdn.microsoft.com/en-us/library/system.windows.uielement.focus.aspx
The accepted answer here does not solve the problem of textboxes who dont gain focus, no matter what the debugger tells you. If you have and can write to your textbox, then you have it keyboard-focused.
I found this here solving the problem (and actually gaining focus, not just settings the values so it looks like focus in the debugger), it comes very close to Pavlov's answer but with the "Focus code" : Keyboard.Focus does not work on text box in WPF
This worked for me (had to do UpdateLayout, otherwise Focus() didn't work immediately after changing tab from script)
tabControl.SelectedIndex = 2;
this.UpdateLayout();
txtMyTextBox.Focus();
It's important where your first two lines of code are executed.
If they are in an event handler that relates to the user pressing a key, using the mouse, altering the visibility of a control, or otherwise taking an action that might have an impact on focus, I find manually calling Focus() often doesn't work.
My theory is that internally, WPF operates as follows:
User or code takes action which could have an impact on focus, e.g. a TextBox control becomes enabled inside a focus scope which previously had no focusable control.
WPF notifies various event handlers, including yours which calls Focus().
WPF updates focus based on the state changes in step 1. This overrides whatever you did in step 2.
That is why this answer suggests to call your Focus() in a queued callback which will be executed after step 3.
Side note: you don't need to call both UIElement.Focus and Keyboard.Focus since the first includes the second (at least if you trust the Microsoft docs).
In conclusion, replace your first two lines of code with this:
// using System.Windows.Threading;
Dispatcher.BeginInvoke(DispatcherPriority.Input, MyTextBox.Focus);
I 'm running into a situation i don't understand and want somebody to enlighten me if possible.
Created a WPF application. For sake of simplicity consider this application to be one window. I put some controls on this window, amongst others there is a TextBox control (let's call it TB).
There is a requirement that this TB must always have the focus (in case someone types something or something is read through the barcode-scanner it should appear there).
I thought implementing this with the help of a timer: every second the focus is transferred to the TB.
Until now everything works fine (as expected).
The weird thing is the following: let's say a new user wants to use this window, so she has to sign in. I thought implementing this with a new Window object (let's call it W2), calling it this way:
W2.ShowDialog();
This W2 window should be modal (bear in mind that the timer still executes).
The crazy thing is that under Windows Vista this works perfectly as expected (this means W2 is modal and the user can to what she should do on W2), BUT on Windows XP as soon as the user wants to type something in a textbox of W2 the focus is set back to TB on the initial Window (as far as i can interpret: this means W2 is not modal!!!? am i right?).
How can i overcome this situation?
Is this the right approach?
Thanks in advance
Make sure to set the Owner property of W2 to your main Window.
From the referenced docs:
When you open a child window by calling ShowDialog, you should also set the Owner property of the child window.
I am not sure this setting-the-focus-back-every-few-seconds is such a good idea. It is always possible that some input will come in the interval between a lost and got focus state (and be lost). Alternative solutions are catching the PreviewKeydown event on the form that the TB resides on and somehow set the output of a barscanner to the TB too.