I am not getting it after quite a research, that how can I implement simple Lostfocus like we use to do in Winforms. In Windows Form Control, we usually have LostFocus which I use when someome press TAB to lose focus or use mouse to select other controls. But it is not the case with WPF. I first use LostFocus, but when i press tab it doesn't fire the event. however when I click using mouse to other control it does get fired properly. So, this doesn't solve my problem.
Second, I try to use LostKeyboardFocus, it does get fired when using TAB key, and on few occassion when I use mouse to select other element, but not when I select menu item from Parent window menu.
Also, I have my control on User Control, that I put in TAB control on parent window. But when I press TAb key it always select the Parent Window Menu instead of TreeView I have in UserControl.
Any suggest is great help. Thanks.
Well, my quest for finding logically reasoning is still not satisfied, but I get the simple thing done simply.
#Daniel, as I said I think the two questions are related, well the answer is indeed related. Maybe you can explain my finding that I am putting as answer here.
I simply set the TabIndex property of my Textbox and other control [TreeView] as 1 and 2, now when I press TAB or select the TreeView item using mouse, i got Lostfocus fired up. and since I have Tab Index set within control, it doesn't select Menu item of parent [it does select it as last now]. So that make Lostfocus the function I should use for my purpose.
Anyone with explanation or better solution is still requested to share it. Thanks.
Related
I have multiple controls on one form,and when i select some value from combo box(for example 1) next control became enabled, else next control stay disabled.
Problem is that if i just press 1 and tab, after that next control became enabled, but program jump over it just like control are still disabled, and tab control selecting next control.
I need to find way how to tab check is control become enabled and go on this control,and if control are still disabled that go on next enabled control.
Thanx
You created a mousetrap for the user, very hard to escape from. Technically you can handle the keyboard navigation by trapping the Tab key before it can be used to navigate but the user still has an unsolvable problem when he wants to use the mouse to change the focus. He has nothing decent to click on.
You'll need to re-think your UI design. One possible solution is to change the ComboBox's DropDownStyle to DropDownList. Which ought to be pretty appropriate if you use its selected item to enable other controls, there should only be a limited set of valid selections. If that's not what you want then you need to do something drastic. Not necessarily limited to hiding controls instead of disabling them.
This is probably caused by the event of the combo-box you using to control your flow.
The "Changed"/"Value changed" events in most languages fire up after the control has lost focus.
You forgot to add a tag for the UI technology you are using.
If you are using WinForms, then you can try to execute the SelectNextControl method on your control that the user just edited. This will find the 'next' control for you, and activate it.
Lets assume it's winforms (playing with disabled/enabled like this in wpf is.. against mvvm rules).
Firstly, ensure what tab order/index of your controls is ok. To test, if they are all enabled, then pressing Tab should go through them in the right order. This can be seen easily
Next thing is to choose one of many possible solutions, to make 1,Tab to work:
disable Tab key navigation at all;
make controls to pass control (focus) to specific control (making tab order irrelevant);
use SelectNextControl (work best for custom controls, which when will support that tab-flow schema);
prevent focus changing, do all logic, change focus (theoretically).
I am trying to replicate an intellisense like feature where you have a textbox and a menu that's shown below it. I know intellisense doesn't use ContextMenuStrip, but my version has to have categories which are sub-menu items.
So as soon as the user clicks into my TextBox, I bring up the menu below once, but then even though I can see the caret in my TextBox it doesn't receive any key inputs. I have to click inside the TextBox again but that removes the menu from the screen.
Is there a way to prevent this? Or perhaps make the menu persistent on the screen without stealing focus?
ToolStrip control with items added to it seems to work since it's always on the form.
In my application I have dropdown list with several items. I'd like to show a context menu when the user clicks the right mouse button on a dropdown item. Is this possible? And if it is possible, how?
It is possible but not easy. The ComboBox dropdown is a native ListBox that is created on-the-fly. To get the handle of that list box, you have to send the CB_GETCOMBOBOXINFO message in the DropDown event. Check my answer in this thread to find out how to do this.
The iceberg that is likely to sink that Titanic is that the dropdown automatically closes as soon as it loses focus. Which will happen as soon as you display the context menu. Nothing you can do about that.
Consider a different approach, you could use an actual ListBox that you make visible when the user clicks a glyph that looks like an arrow next a TextBox.
Not possible easily. No hover or right-click event messages are being sent when the combobox is expanded.
You can see this is the case when using Spy++.
I think the easiest would be to change to a listbox if your scenario allows you to do that.
As Wim said in his post, there's not a direct way to do this because the messages you want aren't fired.
As a comprise, you could try setting DropdownStyle=Simple; on the Combo and
shrink the scroll region to show a single line:
http://img34.imageshack.us/img34/1695/49557147.jpg
If you assign the Combo a context menu, it will open when the scroll region is right-clicked. You'd probably have to figure out what item was right-clicked. But as other have said, this doesn't sound like a standard Windows way or an intuitive use.
Or how about a modal dialog that you could bring up from the Combo's context menu? On the dialog, you could have a list that the user could select from and a Delete button to delete the selected item(s).
Since MenuItem doesn't have a ContextMenu property it isn't as easy as it is with many other controls. You'll probably need to capture the right-click event and then position and show the context menu manually.
Two caveats though:
The combobox list will close when the
list loses focus, so it may close
when the context menu is shown
leaving the user unclear as to what
they clicked on (not 100% sure on
this, since I haven't written the
code to test.)
More importantly though I would argue
that this is a poor UI choice, I
can't think of any real world
applications I've used that have
context menus on menu items, so it
wouldn't be very discoverable for the
end user. Plus context menus should
be just for quick access, they
shouldn't be the only way to access
functionality. Are you going to be
able to expose these functions
through other means as well as the right-click menu?
You could do it manually, by capturing the event on the form, but consider making a nested menu instead. If your combobox items have menus of their own, combobox probably isn't the right choice.
For those asking "Why?" or saying they've never seen a combobox with a contextmenu; Look at any web browser's favorites dropdown. You can right click and delete, edit, or go to the entry in current tab, new tab, or new window.
I also could not get an actual contextmenustrip to show, so I made a menu with a small borderless form and call with:
Private Sub FavoritesBar_SelectedIndexChanged(sender As System.Object, e As System.EventArgs) Handles FavoritesBar.SelectedIndexChanged
FavIndex = FavoritesBar.SelectedIndex 'FavIndex is declared as a public string.
Dim Loc As Point = New Point(MousePosition)
FavMenu.Location = Loc
FavMenu.ShowDialog()
End Sub
With a homemade contextmenu, be sure to add "me.close" at the end of each sub as well as the me.mouseleave event.
I'm working on a custom user control that essentially displays a name value pair (name is on a black background, value on a white). I have my control displaying correctly, even showing up in Designer and on my build page.
What I'd like to do from here is have the ability to right click on the user control and have a menu come up that has a "Copy Value" option, that when selected will copy the value in the "value" part of the user control to the clipboard. What is the best method of approach?
I'm not sure where to start since most of the documentation on user controls I've found deals with displaying the control, not necessarily interacting with it. Additionally, since I'm still learning C#, I might have left out an important part of my problem in this question, so please point that out if it's the case.
I'm using Visual Studio 2008 (if that matters).
Examine the ContextMenu control and the ContextMenu property of other controls. By assigning a ContextMenu control to the ContextMeny property of another control, you will have the right-click->popup menu wiring done for you. Then you only need to implement the click event of the different menu items in the context menu.
Then you can use the Clipboard.SetText (as suggested by BFree) to set the desired value to the clipboard.
Add a ContextMenu to the control. The, hook into the MouseClick (or MouseDown, whichever works better) event and if it's a Right-Click, then call show on the ContextMenu (there are a few overloads, try to mess with them see which works best for you). Then, in the click event of your context menu, just call Clipboard.SetText(...) to set the value to the clipboard.
I am adding a label to a form dynamically, then dynamically adding a ContextMenuStrip control. Whether I use the label.ContextMenuStrip property to connect them, or add the event handler to the label manually to have it respond to the right-click and show the context menu, I get odd behavior:
1) The menu does not appear next to the mouse pointer, it is offset down and to the right. It appears that it is related to the position of the label in it's parent control (a picture control), rather than the form.
2) The menu does not disappear when I click on something other than the menu.
Any ideas what I am missing here?
Thanks,
Andy
I worked it out. First off, I was adding the control to the label control collection, changing it to the the form collection corrected the positioning problem. I never did figure out why the menu would not close.
Ultimately I restructured things by adding a static instance of the menu to the form, then just connected the label.ContextMenuStrip property to that stastic instance. All is well with that approach.
I used the tag of the label control to identify it to the click event handler.