TextBox behaves differently when losing focus in different ways - c#

The WinRT TextBox control has a delete button that shows up when the control has focus and there is text in it.
When the control loses focus by tapping outside of it or tabbing outside of it, the delete button disappears.
When the control loses focus by tapping in a different app (two apps are up in splitscreen), the delete button doesn't disappear.
Is there a way to detect the different lost focus events? Nothing from the sender or RoutedEventArgs is different in the two cases where the control loses focus.

You can handle Window.Activated to check if the whole app has lost focus:
This event occurs when a Window has been activated or deactivated by
the system. An app can determine what the status of the Window
activation is by checking the
WindowActivatedEventArgs.WindowActivationState property. A Window
could be visible on screen but not be active (for example, in snapped
apps). Additionally, if any other parts of the system takes focus away
from the window, this event will occur. This could happen as a result
of user interaction or code, and the WindowActivationState will
indicate which action has taken place.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.window.activated.aspx

Related

Keystroke not monitored after clicking on buttons

I have made a game where the character moves using wasd. In the same form on the right side there are some buttons and other controls but when they are pressed the character wont respond on keydown events. How can I solve that?
Explanation:
This is because Windows has the concept of "Focus". (Read up on it.) Key events are only sent to the control which has focus, and at any given time only one control within the form has focus. You probably have some control which renders your character, and you have placed your key event handlers on that control. When the form first pops up, you give focus to the rendering control, so everything is fine. But as soon as you click on another control, that control takes focus, so your rendering control does not have focus anymore.
Solution:
After a button gets clicked, use SetFocus() to return focus to your rendering control.

How to change default behaviour that a textbox loses focus on back button pressed

The default behaviour of pressing back button when a textbox is on focus is that the virtual keyboard closes and the textbox loses focus. And the user press back key again, the window goes back to previous window.
However, I want the change this behavior. I want the window to go back to previous window directly when the back key is pressed, ignoring whether the textbox is on focus or not.
I tried the following methods,
Use HardwareButtons.BackPressed event, doesn't work (maybe it only works for Direct3D, I am not sure). The event isn't fired during back button pressed.
Use Textbox_onKeyUp, doesn't work. The event isn't fired during back button is up.
Use override void OnBackKeyPress, doesn't work. It does fire as expected during other cases, but during the situation when the textbox is from on focus to losing focus (the keyboard closes), the event isn't fired.
Use Textbox_OnLoseFocus, works fine but need a lot of condition checks because some times losing focus doesn't mean that I want to go back to previous page.
Please help. Thanks.
Finally I didn't change the behaviour, made a different design. But I still think that in that case, the Nokia's behaviour is most user-friendly.

Interacting with a form without it activating

I'm trying to implement code-completion popup window in my project. The window is derived from Form. It contains two controls: custom list derived from UserControl (it shows completion possibilities with icons) and a VScrollBar.
When the popup appears, it doesn't steal focus from the editor (form's ShowWithoutActivation is overriden to return true) and the editor sends certain keystrokes to the popup so the user can interact with it using keyboard. So far it works like a charm.
The problem is, I want to allow the user to use mouse as well. But, when the user clicks into the popup window, its form activates and steals focus from the editor. I can react to this by giving the focus back to the editor, I have even set up a Timer to do this regularly, but apart from being a poor solution, the title bar of the editor always flickers when this happens (when the popup is clicked).
Is there any way to interact with the popup form (using mouse) that doesn't make the form activate?
The ShowWithoutActivation's documentation reads: "If your non-activated window needs to use UI controls, you should consider using the ToolStrip controls, such as ToolStripDropDown. These controls are windowless, and will not cause a window to activate when they are selected." This seems exactly like the thing I need, but I want to use a custom control and a scroll bar.
The same problem would be with a tooltip that shows these two arrows to switch method overloads (known from VS) - the whole form would use no controls at all (only render the text and the arrows), but when clicked, it should not activate. The problem could be summarized up to "How to create a form that would never activate, but allow the user to interact with certail controls inside?".
Thanks.
Just override the onFocus event...
public partial class myListBox:ListBox
{
protected override void OnGotFocus(EventArgs e)
{
}
}
The issue is that you're using a Form for this rather than building some custom control that doesn't run in its' own UI thread like a Form does.
The flashing and highlighting is handled by windows whenever a Form activates/focuses. The only thing I cay think of is to make your Form borderless and create/draw/handle your own title bar that doesn't flash when focused.
OK, I may have found a solution. The key seems to be WM_MOUSEACTIVATE message, which the popup form must intercept and respond with MA_NOACTIVATE. But there's a catch - the control derived from UserControl still grabs focus when clicked (the scrollbar luckily doesn't anymore). The problem seems to be in the UserControl.OnMouseDown method, which internally puts focus on the control. There are some ways to fix this:
derive the control from Control instead of UserControl
override the OnMouseDown method and not call base.OnMouseDown there
make the control's CanFocus property return false, but this seems not possible, because that means to make the control either not visible or not enabled, which is both undesirable
The last case when the popup form steals focus seems to be when its resizing (using mouse) ends. But it is safe here to call Owner.Activate() as a result to Activated event...

Show/Hide ContextMenuStrip outside the form

I'm creating a simple clipboard manager application. It monitors the content of a clipboard. When a change occurs (throu the win api message loop) it fires up a method to capture current content of clipboard and creates new object called clipboarditem. Next its building a ContextMeuStrip which consits of several clipboarditems created previously. The items menu is accessed by a hotkey. It shows up this menu on certain position of the screen itemsMenu.Show(caretPosition);, with .Focus(), I want it to make it disappear after it loses the focus (eg. clicking somehwere else on the screen or switch applications by alt-tab). Found an event OnLoseFocus but I dont think its working properly because the menu wont even show up.
How to make ContextMenuStrip disappear after loosing focus and how to prevent from showing ContextMenuStrip in taskabr ?
Sorry for my language skills :)
From a very quick look at the events that ContextMenuStrip contains, have you tried the "MouseCaptureChanged" event? It may help you with the losing focus issue.
For the showing in the taskbar issue, have you set "ShowInTaskbar" to false on the form you have your ContextMenuStrip (if you have it on a form)?

How to do two things with one click in Windows Form

On my main form, there is another (floatable) window. This floatable window works sort of like a popupwindow in that it will close when the user clicks somewhere else outside of this window. This is handled by the Deactivate event. But what I want to do is, if the user clicks on a different control (say a button), I want to both close this float window and then activate that button with just one click. Currently, the user has to click twice (one to deactivate the window and once more to activate the desired button). Is there a way to do this with just one click?
foreach(Control c in parentForm.Controls)
{
c.Click += delegate(object sender, EventArgs e)
{
if(floatyWindow != null && floatyWindow.IsFloating)
{
floatyWindow.Close();
}
};
}
And then add your handlers as normal. This additional handler can close the floaty window.
Make sure you floaty window isn't a dialog too as this will not allow your parent form's controls to be clicked.
I had a slightly hacky solution. In your Deactivate event, fire another custom event to your main form. Then when you main form is handling the custom event, enumerate through your control(this.Controls) and locate the control under the mouse by checking all their bound then call Focus(). You might need to sort by the one with the smallest surface area, or you can have a separate list of "focus-able" control like button just for this purpose.
Another way might be to switch focus to your main form immediately after OnMouseLeave of the floatable window, or OnMouseHover of your main window, but keep the floatable windows on top, just no focus. Handle the global mouse down of your main form, and close the floatable window by then.
These are just theories, not tested.
I had an issue like this once too, when a customer wanted "floaty" windows all over there application. I used used an approach similar to the one described in this article:
http://www.vbaccelerator.com/home/NET/Code/Controls/Popup_Windows/Popup_Windows/article.asp
Code sample available here:
http://www.vbaccelerator.com/home/NET/Code/Controls/Popup_Windows/Popup_Windows/Popup_Form_Demonstration.asp
By extending this a bit we created "floaty" windows similar to the ones VS uses when you get a runtime error while debugging code.
At the very least reading the code may give you some insight, however, quarrelsome's response may be the more simple solution.

Categories