I'm working on an application which uses numerous panels which are swapped at runtime. The swapping of the panels is controlled by handling keydown events and examining the current "state" of the application to determine how to route the keys.
I was doing some cleanup work in the form designer moving panels and labels around and now i've somehow disabled my main form's ability to pick up the tab key in my keydown event. I still get all other keys, including enter key.
The code didn't change and was very much tested to function fine with a tab key, so I can only imagine I accidentally turned off some important property when playing in the designer.
I have keypreview turned on in my main form. Since I get other key events I do not believe that my keydown handler is working incorrectly. Somehow my form just stopped feeding tab key through. TabIndexes are sequentially numbered but they should not matter since I am using keypreview to process the event before letting tabindex determine its next jump.
I figured this might be an easy one for somebody who's been there and fought this before. I have backups with the tab key still functioning but i've made leaps today in the logic so i'm not quite ready to roll back or do a side-by-side compare of every object on the form.
That's not supposed to work. And won't when you have any controls on the form that can get the focus. The Tab key and the cursor keys are used for navigation, moving the focus from one control to another.
The KeyPreview property is a VB6 legacy compatibility property, used to implement custom shortcut keystrokes. The code that intercepts the navigation keys runs before the code that fires the form's KeyDown event. You instead should override the ProcessCmdKey() method, it runs before the navigation code so can see the Tab and cursor keys:
Protected Overrides Function ProcessCmdKey(ByRef msg As Message, keyData As Keys) As Boolean
If keyData = Keys.Tab Then
'' Do something, preferably navigation related since that what the user expects
''...
Return True '' That means that the key was consumed
End If
Return MyBase.ProcessCmdKey(msg, keyData)
End Function
I searched for tabstop and looked for an object with this as true.
My "find" in VS didn't find anything but then I saw a listbox on the last panel I added to my project that had tabstop turned on.
Turning this off got me back to where I originally was at with my code picking up the tab key.
Related
I have a long running application written in VBA. Because it runs for a long time I call a sub from the main loop every iteration to check if the user has pressed the escape key. The sub is listed below. The code works great except that it is always listening, even when the VBA application does not have the focus. What's the best way to approach this? Is there an alternative to GetAsyncKeyState which only listens when the correct application is in focus, or are there system calls I can use to check that the correct window is in focus.
Private Sub checkForUserEscKeyAbort()
'Listen for escape key and exit gracefully if user aborts.
Dim abortResult As VbMsgBoxResult
If GetAsyncKeyState(vbKeyEscape) Then
abortResult = MsgBox("Escape key pressed, do you want to abort?", vbYesNo)
If abortResult = vbYes Then Call teardownSLICER
End If
End Sub
The problem is the way GetAsyncKeyState operates. It does more than just check it the key is currently down, it also checks if the key was pressed since the last time GetAsyncKeyState was called. Thus, your problem of "always listening".
You could use GetKeyState, but frankly, I'm not a fan of that option either. Your code must be well crafted to avoid a polling window that is so small that you literally have to hold the key down to ensure it isn't missed.
A viable alternative is key masking where you use a combination of keys such as Shift-Escape. There is a decent introduction to this (and many other subjects) on Chip Pearson's site. However, this is still not my preferred method.
My preference has already mentioned in the comments. Your application may best be improved with a user form. It also gives you the ability to get information in front of the user. Perhaps they wouldn't try quitting the application if a progress bar on the user form indicated 95% completion. Maybe you can add a pause button that free's some resources for a prescient need and then resumes when the user is ready. That little extra functionality on its own is enough to win me over but there is an even better reason for using a User Form - it does exactly what you asked!
User forms, and many user form controls, have Keydown, Keyup, and Keypress events that only trigger when the form (or control) have focus. This is precisely what you wanted.
The user will type in a datagridview the shortcuts he would like to assign to a couple of operations. I tried to use KeyDown event when the cell is in edit mode.
However I want my control to be able to detect in the same event handler the Control key typed alone, or the Control key used as a modifier (same with Shift and Alt).
This causes a problem since KeyDown fires up when Control is down before the other key I am combining it with is also down. Obviously the event handler doesn't know if the user intends on pressing another key after the Control key.
Right now I solved this issue by using KeyUp, but this caused other headaches when for example the user types in CTRL+P, releases P, which fires the correct event, but then the user releases Ctrl which fires a new KeyUp event which I had to find a way to ignore.
There must be a cleaner way to handle this?
Is there any way to test if an event linked to a control is triggered by the program, rather than by user action?
I have a scroll bar which fires events when the user moves it. I want to be able to move the scroll bar programmatically elsewhere in the code without sending these events. i.e. events should only fire when the user interacts with the control, not when I move the control via code.
I also have radio buttons and numeric up/down controls I'd like to b able to do this with.
Thanks
There maybe better ways to do this but a quick way would be to use a boolean variable that you set when you are programmatically scrolling and unset it when you're done. Then in your event check that before executing the logic.
If IsProgramaticScrolling = False Then
' Do whatever it's supposed to do when your program isn't
' scrolling via code.
End If
I have a form that is re-used. That is, instead of creating a new instance of the form each time, the form is kept hidden, and is made visible when needed. (A design I inherited; I presume this was a performance optimization.)
The problem: The second time that the form is used, the focus is on the OK or Cancel button, from the first use of the form.
The user wants the focus to start the way it did the first time the form appears - on the control with lowest tab index.
If there were just one such form, I would hack it: add a line of code hardwired to the desired control.
But there are many such forms, and the visibility logic is in a common base class.
So it would make more sense to do this right, and tell the form to focus on its first (lowest tabindex) control.
Is there an easy way to do so?
(I could iterate through all the controls, but then I have to correctly handle nested controls. Since the GUI has to do this the first time it shows a form, I am hoping there is some method I can call that does it for me.)
(Coded in VB.net, but a C# answer would be fine.)
It is a one-liner, the logic to find the next control is exposed as a method, SelectNextControl(). You should start at the Form object, the one that can never get the focus, and ask it to find the next one in the tabbing order. Which is the child with the lowest TabIndex, whatever value it might have.
So something like this:
public void ShowAgain() {
this.Show();
this.SelectNextControl(this, true, true, true, true);
}
And do consider that a Form object that isn't visible is a rather major resource hog, using up lots of operating system resources for a small convenience. Surely you can also Close/Dispose it and recreate it when needed. YMMV.
You can try to set ActiveControl property before making form visible:
_frm.ActiveControl = null;
This should clear the active control for the form and remove focus from its controls.
All,
I have a TabControl in an application that started behaving strangely. Some background...
This program was converted from VB6 to VB .NET 2008, and used to refer to forms using their class names. In other words, I might have a form class called frmFoo. In the code for the program you might see:
frmFoo.Show()
or
frmFoo.UserDefinedProperty = True
During some recent changes, I created variables to represent instances of my forms much like these:
Public MyForm as frmFoo
MyForm = New frmFoo
MyForm.Show()
In doing so, I also removed code from the form's Load event handler and put it in the form's constructor.
When the form loads, or when a document is loaded and should influence the TabControl's selected index, something like the following will not necessarily fire the SelectedIndexChanged event.
MyForm.tbsForm.SelectedIndex = ValueReadFromFile
...or...
MyForm.tbsForm.Tabs(ValueReadFromFile).Select
Sorry to be so wordy, but there's more. If I open the form and look at the TabControl to verify that it's been set properly, everything works like it's supposed to. The misbehaving TabControl is contained within another TabControl, so I have to click the parent TabControl to see it. If I can see it, and run a test, the test always works. If I can't see it, and run a test, the first test I run will not fire the event. ...paging Dr. Heisenberg...
It's almost as if the control has to be initialized first by changing the value or making it visible onscreen...I'm totally lost on this one. It's the most unusual behavior I've ever seen. And everything worked perfectly before I began using variables to represent forms and placed the Load event code into the form constructors.
Can anyone help, or at least put me out of my misery?
SH
-------------------------------------------------------------- Edit #2
I just performed a test after having attempted to eliminate some of the variability in the behavior. But I wanted to confirm the previously-stated behavior.
I opened the program and read a file. This file contained a value that should have triggered the event handler. Without making the control visible, I can change the SelectedIndex property of the tab control without the event firing.
I closed the program down again, and reopened it. This time, selected the parent tab that allowed the child tab (the one whose event I'm concerned with) to become visible. I then selected a different tab in the parent control, meaning that the child control was no longer visible. When I opened the same file as before, it fired the event.
I'm tempted to implement a flag that confirms that the control has been repainted or whether the parent tab has been displayed. I may have to fire the event in code if the flag isn't set.
I want to reiterate that everything worked when the program referred to the forms by their class names and much of the arrangement of controls on the forms was done in the load event. Now the program creates variables and the arrangement of the controls is done in the form's constructor. I'm sure this has something to do with the problem I'm having, but I can't understand how. Any wisdom to share?
MyForm.tbsForm.SelectedIndexChanged = ValueReadFromFile
doesn't make a lot of sense. Is tha trying to assign a handler to the SelectedIndexChanged event? or is ValueReadFromFile the name of the tab?
What you're saying is that you have two tab controls, say, A and B. Tab control B is contained within a tab of A, and unless A has the tab page selected that contains the tab control B, the SelectedIndexChanged event of B will not fire if you change its tab programatically?
In which different ways have you tried to select a tab within the child tab control, and when is this code being executed?