During development i have observed that certain PDAs with Windows CE and possibly Windows Mobile too are sending the Enter key twice in the key pressed event thus i execute twice the code that lies under the control's key press event for the return button.
I suspect that this is a hardware bug and i would like to ask how you resolved it without changing your application logic.
Without changing the logic? You really can't (unless there is a hardware or firmware fix). I'd guess the simplest mechanism (that requires a logic change) is to treat two Enter keys or keypresses in a short period (say < 100ms) then ignore the second.
I don’t know if this will help but if you read the keyboard port Enter is seen as two bytes rather than one.
This happened to me too and it turned out it was because the "enable character repeat" option was enabled in control panel->keyboard. The default repeat delay was way too fast for the keypad that we used, so I just slowed it down and the problem went away.
Related
When starting our vba-access-application (which is done by a VBE-add-in which starts a VBA-function) we used to close the navigation-pane with this code:
DoCmd.SelectObject acMacro, "Autoexec", True
DoCmd.RunCommand acCmdWindowHide
As I started to use the built-in search/filter bar inside the navigation-pane, this code did not work anymore when the macro "Autoexec" is not visible. So I changed it to:
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
This seems to work fine as long as there are any search results left. When I write "nothing with that name" inside the search bar(=the filter), the navigation pane will not close.
Does anyone know a way to close the navigation pane even if there is no search result visible?
DoCmd.NavigateTo "acNavigationCategoryModifiedDate"
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
In order for the command DoCmd.RunCommand acCmdWindowHide to successfully close the Navigation Pane, the Navigation Pane must have the focus. But for an Access window to have the focus, a control within the window must have focus. It turns out that the NavigateTo command will never place the focus in the Search textbox, so if the search results are blank and there is nothing to select, then focus will not change to the Navigation Pane (even though technically the Navigation Pane's selected group may have been updated.)
If you play with the Navigation Pane long enough, you'll find that the Navigation search results and textbox are reset when switching between the highest-level Navigation categories. Hence my suggested code... it changes between two Navigation categories so that the search results are cleared during that action, so that the Navigation window will eventually gain focus when one of its listed objects finally gets focus.
(Really, using the NavigateTo command in this case is just a stupid trick to place focus on the Navigation Pane. It's just another glaring deficiency of the Access interface that there is no direct commands/objects for controlling the Navigation Pane.)
I suggest you don't write any code—but just use the built in Access settings to prevent (hide) the nav pane.
So work, then you hold down the shift key during startup.
(shift key by-pass).
The shift key development dance:
You will find that you can launch + develop a lot of code and work on forms/reports without having to exit.
However, you STILL will have done a shift key start-up bypass. The reason of course is that on start up, you code may well hide the ribbon. (Or launch a custom one). Same goes for start-up form—it may run a bunch of code, ask for logon, check table links.
And then there is the start-up settings you have. You likely have a start-up form (you don’t want that running). You likely have un-checked the display nav pane, but you need this during development. And what about if you have a custom ribbon? (Again a setting in tools→options). And use special keys—again turned off for users, but REQUIRED for developers.
And then there is the auto keys macro. This is used to re-purpose the F1 key (help—either disable or launch your own custom help—say a pdf or word file).
And any re-purpose such as say an f12 to popup some custom search box etc.
So, all of these custom setup is going to be rather LARGE amount of settings. Many will be from tools→options (main form, ribbon, etc.). And some will be from your code.
You REALLY (but REALLY) can’t code out all of these settings, and some require a re-start anyway. In a typical application there really going to be a lot of settings that are changed for your users vs you as the developer.
On start-up you thus hold down shift key. This will not only prevent your start up code from running, but ALSO your start up settings – even things like nav pane, and especially the tools→settings area (shift key ignores most of those settings).
So during a day of development, I will do this shift key dance all day long.
However, there are two tricks and shortcuts you can use here that will minimize this exit + re-enter down to a dull roar.
One great tick is to always place a custom compact repair button on the QAT. So QAT button is now ONE mouse click and always available to you. So if I am working on a form in design mode, flipping into view mode will often suffice, but in those cases where I need a full exit + re-start to test? I don’t even save the form, I just do a quick simple one click on that QAT compact + repair button.
One click! (Might have to answer yes to save). At this point, the application will re-start without you having to exit. And you don’t hold down the shift key—so all your start up settings run. You now flipped into user test mode, and it only took ONE mouse click.
This allows you to flip from developer mode and into “user test” mode with ease and only one mouse click.
So you can now run your application as it will appear to the end user.
To flip back into developer mode, just one simple click on your custom C+R button. (And you HOLD down shift key). This will flip you back into developer mode (you nav pane, your function keys, everything and all those start up settings are now ignored – you are free to develop without all those hassles and issues in your way). Full wide open use of Access as if no settings at all occurred.
And as noted, you get a c+r to boot, and you need + want to do that multiple times during the day anyway.
And as noted, for a good many changes, you not have to do this flip and can stay in developer mode.
Of course in some cases your “user mode” will REALLY lock down the Access and thus you have to exit (you lose the QAT trick). So you often be able to jump from developer to user, but not back the other way. Again, you not have to run + test everything in user mode all the time, but often some global variables, start up, password stuff will force this issue on you.
So, in this case?
I use a quick hit of alt+f4 to exit the application. AT this point, the accDB file should STILL be highlighted in the windows explorer. So, now it just a quick tap of the enter key to re-launch the accDB. And if wanting “user mode”, then simply don’t hold down the shift key. Do some testing, now alt+f4, and then a simple quick tap of the enter key (we back to the windows file explore and that accDB file is highlight). However, this time you WILL hold down the shift key, and thus you now back into developer mode.
And often, I will call my start up code before testing.
Ctrl+g (jumps to debug window), type in MyStartup
(MyStartup is assumed to be your first start up routine that does all that setup and THEN launches the main form – so in some applications I don’t use the built in start-up form setting, but use the autoexec macro to call my main start up routine (MyStartup)
So in a good many cases, I don’t have to exit Access to flip into test mode.
And of course some reports and forms can be used, viewed, developed on without having to full run the application with all that “user” start-up code stuff.
So some report might work, but then again it may well require some form to be open for it to work. (Or a system wide function and company name setting may be required + set in your start up code). So how badly you need to exit vs that of being able to do “some” development will often vary here.
So I will say that often I am forced to exit + re-load the application (alt+f4, tap enter key). So it only really 2 key combo to exit out and re-load/re-enter Access.
At the end of the day, if you can’t use that QAT shortcut suggestion, then you will exit + re-enter MANY MANY times during the day.
As noted, for a good number of forms etc., then you can flip between view and design mode. (But you of course be running access without all that start up crap stuff that prevents you the developer from working).
The simple matter is at the end of the day, there is going to be FAR MORE settings then just the nav pane (or lack of) that going to mess up your development process. So, the above shift key dance and QAT suggestion ALSO solves all of the OTHER many settings, and does so without you having to write one line of code to deal with this issue.
Of course, once all is working, then you will compile the application down to an accDE. And then apply the shift key by-pass code to that to lock the application further down.
This is an issue I've ran into before, but I've always given up solving the problem and worked out a work around. Not today (hopefully).
I'm trying to make a bot for the classic Doom II. I want my bot to have access to the main menu which is accessed via the escape key. Naturally I tried:
sendkeys.send("{ESC}")
No luck. But then something weird happened. I accidently ran the code when I was already on the menu... and it closed the menu (which is normal if you press escape on the menu). So clearly Doom II listens to Sendkeys.
I've since tried sendinput, postmessage, and simulateinput. None have worked (they all have the same behaviour as described with sendkeys).
It would be great if someone could ride in on a white horse and give me code to get around this issue, but outside of that can any one simply explain this behaviour to me?
It seems that Zandronum does not accept virtual keys to be sent to it when the game is running (not paused). I'm not sure but it seems that virtual keys might actually be window messages, like Andrew Morton said (or they're at least something similar...). The workaround to this was to send a hardware scan code instead of a virtual key code.
A hardware scan code appears to be the code sent by the actual keyboard when pressing a key, while a virtual key code is the key which the system interprets from the scan code (reference).
So I managed to send keystrokes to Zandronum (both fullscreen and windowed) using a few WinAPI functions:
SendInput() which is used to send the actual keyboard input.
MapVirtualKeyEx() which is used to convert key codes to scan codes, or vice versa.
GetKeyboardLayout() which is used to get the user's current keyboard layout (I, for example, have a Swedish keyboard).
By using the below helper class (or more correctly: wrapper) that I built you may now send keystrokes (hardware or not) in a simple manner, with a larger variety of keys than what SendKeys.Send() includes. You may use any key in the System.Windows.Forms.Keys enumeration.
This was tested with Zandronum and works completely:
InputHelper.Keyboard.PressKey(Keys.Escape, True) 'True = Send key as hardware scan code.
EDIT (2019-09-20)
InputHelper has since long been moved to its own library. The answer has been updated to reflect this change.
Download InputHelper from GitHub:
https://github.com/Visual-Vincent/InputHelper/releases
Just for fun, I also managed to find a list of scan codes on the MSDN: https://msdn.microsoft.com/en-us/library/aa299374(v=vs.60).aspx
Since I'm a Doom fan myself and familiar with how it works, perhaps you should (per your old question) also make sure that you have selected New Game in the menu before you make it press enter?
Zandronum is aware of the names of the menu items, so you just have to give it the first letter and it will jump to the item starting with it:
InputHelper.Keyboard.PressKey(Keys.Escape, True) 'Open the menu.
System.Threading.Thread.Sleep(100) 'Small delay to let the menu open.
InputHelper.Keyboard.PressKey(Keys.N, True) 'Jump to the "New Game" menu item.
InputHelper.Keyboard.PressKey(Keys.Enter, True) 'Go into the "New Game" menu.
InputHelper.Keyboard.PressKey(Keys.Enter, True) 'Start a new game.
I've tested the above code in-game, running in fullscreen mode. Works like a charm.
I need a program to respond while not active/not selected by user or minimized to KeyCodes.
Anyone got ideas? In VB.NET.
This won't work out of the box as key messages are only sent to the active window. A minimized window is never active.
What you could try is register system-wide hotkeys. You could also try to install a keyboard hook, however, this would affect the entire system and your application would receive all the keystrokes performed. This would require efficient filtering.
I am implementing a text service on windows. Things work fine. However when I shift window focus to another application and shift focus back to the original application, the selected text services gets de-activated (I notice a call to ITfTextInputProcessor::Deactivate). I think this call is unexpected. Post this call, The service has to be re-activated manually. I am surely doing something goofy. Just that I don't know what it is.
Offhand, I'd say that you are indeed doing something goofy. :) In particular, I'd pay careful attention to your ITfThreadMgrEventSink::OnSetFocus implementation (and, obviously, you need to implement ITfThreadMgrEventSink in your text service and connect it via AdviseSink if you haven't already.)
After more research, I've figured out what’s happening:
When you set focus back to Word, TSF gets the current thread’s active keyboard layout (actually a locale ID).
It then compares that keyboard layout with the language ID of the currently active text service.
If they’re different, TSF then activates the text service for the active keyboard layout, and deactivates any previously active text service.
I believe this behavior is different on Vista/Windows 7.
The fix would be to use LoadKeyboardLayout/ActivateKeyboardLayout to set the process keyboard layout in your ITfTextInputProcessor::Activate implementation. Apparently some apps also need you to call ITfInputProcessorProfiles::ChangeCurrentLanguage() as well.
How can I bind a key combination to my vb.net application? I know it has SOMETHING to do with the registry, but I have no earthly idea what or how to go about doing this. I want the user to be able to hit those keys when the app is open and have it execute my function, but not while the app is closed.
Thanks for the help!
If you are using a dialog, then you can put '&' into the text for some controls (buttons, checkboxes, radio buttons, etc) and this will cause Alt plus the next character in the text to be used as an accelerator/shortcut. i.e. "&Open" would activate the Open button if you press Alt+O. "Op&en" would activate if for Alt+e.
Beyond that, as Jason Irwin said, you need to add an event handler to your Form for KeyDown or KeyPress events, and then check if the keypress is the key combination you are interested in. This will only work if the user activates your form (clicks in it to give it the input focus. If they put it behind another window, it will not react to the key presses)
If you don't want to show a form, or want to react to keypresses when you're not the input-focus application, then it gets a bit more complicated (you either need to use a hidden form or a keyboard hook)
edit
OK, it looks like you want a keyboard hook. This looks like a good article.
It depends on what you are trying to do:
If you have a gui application and you want to handle key events then you can do that in a keydown eventhandler
If you want to do more low-level stuff and have an application that will intercept all key strokes (regardless of whether or not the application has focus/is visible) then you need to use pinvoke to hit the win32 apis. I suggest you read the following:
link text
Please let us know what you are trying to do so we can provide better feedback.
Using Google, I found this Keyhook example.
I've worked with keyhooks before, in Delphi WIN32, so I am a bit familiar with them. (Just not in C#.) If you add one to a DLL, all Hell might break loose since most virus scanners will recognise this as malware behaviour. (Especially if you use them in the wrong way, causing them to be injected in each and every process that's running on your system.)
A keyhook will allow key combinations to be captured from other processes, though.
For a solution without programming requirements: Drop a shortcut for the application on your desktop. Edit it, assign a shortcut, close it. Press shortcut to test...