Alt + Tab / Windows Key
Blitz3D Forums/Blitz3D Programming/Alt + Tab / Windows Key
| ||
| Hello, I'm wondering how people have overcome the problems from Alt+Tab and the windows key when in a fullscreen blitz3d app. I am having a few complaints from people playing my latest game because of these keys. The windows key seems to cause random results, on my computer it just caused a froze the system for 30 seconds then reported a device driver failure (the graphics card driver) putting me in a 640x480x16 safe mode until I reboot. Alt+tab usually does nothing more than pause the code for me, however for other people it can MAV the game or cause more sever errors such as a blue screen for people on windows 98 or a complete system lock up... this seems to vary from PC to PC though and may not occur everytime. Is there a way of disabling these keys? (I'd love to see an example if someone has one) |
| ||
| I was answering a question about my 'Disable Sticky Keys' dll, so i thought I would check this out on the MS website. Here is a relevant article... Disable Task Switching If no-one comes up with an easy way to handle this I may add this functionality {read: re-write from scratch to use a keyboard hook ;-) } to my dll, as disbling the Win key and ALT+TAB would fit with that. |
| ||
| I think that Ctrl+Alt+Del should be left in place, but it would be really useful to disable Alt+Tab and the Windows key - these ALWAYS mav on my machine, and a few others I've tried it on. Yes please, BlackJumper, go for it. We'd be very grateful. |
| ||
| Yes I'd be very greatful too. However as John said I think Ctrl+Alt+Del should not be disabled... not that it helps me out much on Windows XP anyway :) |
| ||
| BlackJumper, are you planning to add this functionality? Unless anyone can think of an easy way to fix it of course. |
| ||
| I am in the middle of a house move atm and may take a wee while to get my coding environment sorted out, so I doubt I will get this sorted within the next couple of weeks. But, yeah - I will have a go at re-writing my dll to handle these annoying keyboard intrusions. I would appreciate if in the meantime people could also post here any additional 'keyboard annoyances' that they think would fit in with the dll. I can't promise to include your suggestions, but I might as well try to tackle the whole shooting match rather than coming back for a re-write every few months when a new problem pops up. Disable StickyKeys dll - features so far: ========================================= 1. Toggle (StickyKeys + FilterKeys + ToggleKeys) on and off... affects all of these simultaneously 2. Toggle ToggleKeys on and off (since you might want to re-enable this after switching off all of the above) (3) restore all user settings back to original values when you exit the program... even if the program crashed last time before it managed to put things back properly. :-) Planned Features: ================= 4. Trap the Windows key presses 5. Trap ALT + TAB key presses Requests: ========== ????? |
| ||
| Good to hear! :) |
| ||
| It's bad to disable these features as they are there for a reason and your program might not properly restore them. They tried to do it in Quake also, but most people agreed that it was broken to try to do it to begin with. As for MAV it could be bad drivers not restoring the vertex buffers and other DX stuff properly. |
| ||
| Well the start key is the only one I really want to disable because it can accidently be pressed during game play (Ctrl & Alt are both used so if they miss that may hit the windows key). As for Alt + Tab, i intend to give the user the option to block this, but not force it on them (on by default, warn them that it may completly crash their PC if they try to use it) If Alt+Tab worked without crashing or only resulted in a MAV then I'd leave it. But as it can crash the graphics driver, cause a complete lockup or cause a blue screen on older windows I feel that I need to at least warn users before it happens. |
| ||
| Nice one. Go for it King Dave. I'm looking forward to being able to make your dll a standard part of my development suite, as much as blitzsys.dll. And of course credit you! |
| ||
| Not me making it :P Give BlackJumper the credit :) |
| ||
| Whoops, sorry BlackJumper. Err... go for it. @ozak: "they are there for a reason" Yeah, so's the blue screen of death. And I still get that. |
| ||
| OK... I'm on this as soon as I get my Annual Report off to Companies House. {Or I may end up writing it from prison :-) } |
| ||
| I really need this as well for my game!!! It would be incredibly useful!!! Go for it!! |
| ||
| I'm kinda surprised this hasn't been brought up before... or maybe I've just not looked in the right places |
| ||
| yeh could use this:) hmmm, blue screen... been a while since I've seen that. Something must be broke:p |
| ||
| Hi Nicoust - I think you missed my point. How about this (one of my catch-phrases after working with PCs for 25 years): "Windows, yeah, the only operating system that can't even shut _itself_ down!" |
| ||
| BlackJumper, I would love to use this to disable the Windows Key, since I'm making a game for small children. |
| ||
| Version 2 of StickKeys_dll is available in the Code Arcs. Check it out I have added a Low Level Keyboardhook to trap the task switching keys. The sample code has to be the most boring ever made... Someone please post an asteroids example that uses RightSHIFT for thrust, LeftSHIFT to fire, WIN key for shields and ALT+TAB to hyperspace. Please... ;-) It was an 'interesting' project... I now know more about windows hooks than I ever wanted to. What I still don't really know is how to get Borland C++ Builder (V5) to share dll data segments properly... I eventually resorted to 'black magic' coding as their simply isn't any proper documentation out there. At one point I managed to inject the Key filter into all running apps then fail to unhook it... Try fixing your system when you can't actually type anything. :-( This persisted after cold re-boot... very worrying (and a warning to make sure you close this down properly - details in the examples.) Finally had to use a Restore Point to get normal keyboard operation back. Having said that... please test this and post any problems you have. I am especially interested to know if there are issues based on the User Level of the current user... do Restricted Users have problems with this ? {I'd love to answer for you, but I have spent two days on this and its now 6 a.m. - so I'm going to bed now.} |
| ||
| "Partial blame goes to King Dave (original request for blocking task switching)" haha :) Nice work! I tried simulating a crash to see if the system keys would still be locked out in other programs, glad to say that they wern't :) Hmm, sadly you can't detect system key combos being pressed (only one is detected). I'm glad the Ctrl+Alt+Del combo still works, the user needs some emergancey way to get out. |
| ||
| BlackJumper you have officially become one of my heros. A superb piece of work! I'll probably even write a little app for myself that just disables that bloody Windows Key! |
| ||
| Yeeeees!! That's GREAT, and working perfectly!!! Be 100% sure that I will use your dll in my game!! Thank you very much for that! Ex-cel-lent! |
| ||
| I'm glad the Ctrl+Alt+Del combo still works, the user needs some emergancey way to get out. I don't think it's actually possible to turn that one off - it's like hard coded deep in the bowels of Windows... |
| ||
| Glad to finally make a positive contribution to the community. :-) Thanks to King Dave for taking the brave step and simulating the in-game crash to see what happens... and thankfully it seems to be good news. Hmm, sadly you can't detect system key combos being pressed (only one is detected). I'll probably even write a little app for myself that just disables that bloody Windows Key! Now that Version2 is 'out there' I will give a little while for any unforseen problems to manifest (and hopefully get de-bugged) before I move on to write version 2.1 - this will allow individual tweaking of which SysKey combinations are enabled/disabled and may also have some sort of return value so that you know what got blocked. To do this I will need to be fairly confident about what is going on with the 'shared dll memory' tricks. But I think it should be do-able. I'm glad the Ctrl+Alt+Del combo still works, the user needs some emergancey way to get out... I don't think it's actually possible to turn that one off - it's like hard coded deep in the bowels of Windows... Not quite true, but more trouble than its worth to try dealing with. A keyboard hook won't trap it, but you can replace the explorer shell; the security logon routine (GINA); etc. - often with simple registry hacks. These would still popup dialogs however, disrupting game-flow, so they are not 'solutions' to the problem of intrusive keys. |
| ||
| Hmm, this whole issue is a strange one - all these keys behave as expected on my machine. The Windows keys get completely ignored when in fullscreen mode and Alt+Tab lets me switch in and out of my app with no apparent problem. I wonder if the whole problem is related to s specific version of Windows, or even a specific version of Blitz3D? I have: Win98SE, Blitz3D v1.88 |
| ||
| @big10p: ======== Thanks for catching that big10p... I think that Low Level hooks may only work on NT versions of windows...{The DOS-based ones may use a higher level hook that only examines the message queue on a per application basis.} I will check up on that and may try to build in an O/S detection routine that figures out whether it can work or not. There are (I thought superceded!) ways of tackling task-switching in W98 and WinME that I didn't bother to include in this dll. It may be that I will have to include them for completeness. Can you tell me whether the accessibility functions work for you (first check they are enabled in your Control Panel, then try lots of LeftShift or holding down RightShift.) It would be good to know how W98 deals with this... |
| ||
| Just to be clear, BlackJumper: I haven't tried your DLL because, as I said, none of these keys cause a problem on my system. I wasn't sure if you thought I made my post above having tried your DLL. Anyway, I turned on StickyKeys and stabbed the shift keys a load of times while running my Blitz app. Again, it seems to handle things fine - no crash or other misbehaviour. Like I say, this is all a bit strange. Why do I have no problems on my PC but others get MAVs, crashes etc.? Maybe it's a bug in the latest version of Blitz3D? Have you tried downgrading to v1.88 to see if you still have problems? |
| ||
| Anyway, I turned on StickyKeys and stabbed the shift keys a load of times while running my Blitz app. Again, it seems to handle things fine - no crash or other misbehaviour. Firstly, it's not StickyKeys being on that is the real problem... it is the shortcut key to enable/disable StickyKeys that is the issue. [img http:\\www.blackjumper.com\selling\AccessControlPanel.gif] Also, it depends what you term 'misbehaviour'. It's not really ideal in a shoot-em-up that uses the Shift key if you can only fire off 4 rapid-fire bullets before a windows dialog interrupts to ask if you want to turn on StickyKeys. And if that dialog gets 'flipped' from the front buffer before you get a chance to do anything with it, then your user might not even know why the modal dialog is waiting for an answer and your game is refusing to run (a possibility in full-screen mode I believe.) |
| ||
| You will need those alternative methods for Windows 9x. There's some good stuff here on this subject: http://www.codeproject.com/win32/AntonioWinLock.asp |
| ||
| Can I just point out that neither Win95 nor WinME (not sure about 98) are supported by MS. Many companies are now echoing that in their product blurb (including mine). With all due respect to big10p, should you really be worrying about those? - MS obviously aren't. |
| ||
| Yep you should worry about WinME and 98, but not 95. There's quite a few 98's out there if you are aiming low spec. Win98 basically is WinME |
| ||
| What I'm saying is that it would be very nice of you to allow for Win98/ME if you feel it's a good move - but Microsoft don't. |
| ||
| Well, the additional code for W98/ME looks fairly straightforward... as long as I can get a bulletproof way to identify the underlying OS {I seem to remember that there was some weirdness around W98 and W98SE in the way they identified themselves...} there will be no problem in adding this to the next version. |
| ||
| You stilla star and we love you. How long have we been asking for this! |
| ||
| BlackJumper: There is a bug in your nice lib!!! I put it in my game and everything looked fine at first: it was not possible to alt+tab, etc, as expected. BUT I am not able to catch the Esc key!! I have to press the Esc key a million of time before being able to quit the game... Disabling your lib, and it works again... Do you have an idea why?? I use Blitz3D 1.90 and Windows XP Pro... Thanks!! |
| ||
| @RepeatUntil: Is it possible that you had a 'sticky' Ctrl key or Alt key* that is being registered ? The dll catches ALT+ESC and CTRL+ESC. I seem to have no problems in ESCaping in either windowed or fullscreen modes. {* StickyKeys allows you to press CTRL+A by pressing CTRL followed by the A key. It 'latches' the Sys keys until the next key is pressed. If CTRL then ESC was being ignored, it might remain in a latched state ?!?} Were you using KeyboardGameLock() {should have disabled StickyKeys} or individual components when this happened ? Could you try again RepeatUntil (or check your Accessibility Control Panel - see image above) and see whether this explains it ? Can anyone else confirm this unruly behaviour ? |
| ||
| Very strange! I did some additional test, and the results are strange! But first let's answer to your questions: First, the stickyKey option is not checked on my computer. Second, I used KeyboardGameLock() , but separate options produced the same results. Now for the strange results: With this simple program, it works perfectly and I am able to press Esc: KeyboardGameLock(True) While KeyHit(1) = False Wend KeyboardGameLock(False) But still, in my game, this does not work. In my game, I used KeyHit(1). I tried to replace by KeyDown(1) and your lib is now working as expected, and I am able to quit the game with Esc. This effect is only seen with Esc, not with other keys. Would it be possible that your lib interfere with the way Blitz try to catch the Esc key? (which will be seen only for in a long loop, like a game loop) As I said, strange... I will try to investigate more on my side... |
| ||
| Keyhit ====== This command returns the number of times a specified key has been hit since the last time you called the KeyHit() command. Keydown ======= This command (similar to its counterparts MouseDown and JoyDown) is used to detect if a key is being held down. This command returns a 0 if the key is not held down, a 1 if the key is held down. ... but While...Wend should work for any non-zero value returned by KeyHit. Strange !!!! |
| ||
| So I tried to investigate more for this Esc problem. What is sure is that I can Esc with KeyHit(1) without your lib, and I can not with you lib active (with no additional difference in the code). So your lib seems to have a side effect... I did the test with KeyHit(1) located at some other place in my code, and depending where it is located, sometimes it works as expected. Strange! Anyway, I use now KeyDown(1) and your lib, and it's working perfectly. I will stick with this solution. Thanks! Just curious: nobody got this problem? |
| ||
| Cheers RepeatUntil, I will do a bit of digging into this when I get around to producing version 2.1 What keyboard setup do you have... I guess you might be using a French keyboard layout. Is there anything else unusual about your setup... Multimedia keyboard, etc. ? {Not that any of that should make a difference, as the O/S should be fielding any interaction... but you never know !} |
| ||
| Hey BlackJumper. You're really gonna hate me for coming up with more and more requests! How difficult would it be to disable the Insert key? I muts have hit that swine 5 times in the last hour, subsequently (in insert mode) accidently wiping out text then having to retype it. Incredibly frustrating. It's happened again while I've been typing this. |
| ||
| Insert key added to TODO list - I imagine that to be fairly simple to add... the problem will be how to create a simple function interface to the dll to allow sets of keys to be enabled/disabled easily. I am thinking that a system similar to Blitz's texture flags would be best. DisableKeys(options) where options are SYSALTTAB=1, SYSCTRLESC=2, SYSWIN=4, etc. and SYSALL = 1+2+4+8...+128 = 255 Can a .decls contain constant definitions ? These might have to be defined in an 'include' file. Any comments on this approach ? Would people prefer a load of dedicated functions to toggle each state ? |
| ||
| Nice one, BJ. For me, it doesn't matter how you handle the flags - do it to suit yourself. As you say, very often it (frustratingly) takes longer to create the user interface part of a prog than the function it drives. |
| ||
| BlackJumper: my keyboard is an us keyboard, with the option English (United States) in Windows, with no strange option at all for this keyboard (it's a laptop without multimedia key). What could be interesting is to test on another computer if I observe the same "feature". I will do that next week when I will have another computer available... |
| ||
| BlackJumper: I have a small request. There is a file that is created by your lib (stickyKeys.txt). Would it be possible to erase it at the end of the program (ie when we call KeyboardGameLock(False)). It would be nicer for the player of the game... Thanks! |
| ||
| Awesome job, BlackJumper. It works perfectly for me. Thanks! =) |
| ||
| BlackJumper: I have a small request. There is a file that is created by your lib (stickyKeys.txt). Would it be possible to erase it at the end of the program (ie when we call KeyboardGameLock(False)). It would be nicer for the player of the game... At the moment the system works on the basis that a visible file means that either (a) The function has laready been called to disable StickyKeys {so there is no need to disable them again}, or (b) the program crashed before they were restored to their original state ... in which case the 'visible' file is used as the state to restore to. If the system shuts down correctly (e.g. using KeyboardGameLock(false) or SetStickyKeysState(false) ) then this file is hidden rather than deleted. I guess it would be possible to remove it completely, but I thought it would be safer to have a 'hidden' file with the old states in them as inexperienced users would be less likely to simply delete this if there was a problem. Here is a snippet of the C++ code: if (mode == true)
{ // Restore back when going to windowed or shutting down
AllowAccessibilityShortcutKeys( true );
set_file_attrib(filename, FA_HIDDEN); // and hide file to show proper closedown
}I'm open to suggestions on this one. How much of an issue is this for other potential users ? |
| ||
| Since you ask what other potential users think... I'd like to be a potential user. But I tried it, and do not use it, because what it does is too unexpected and complicated in my view and I don't want to spoil other users computers which use my programs. I am a simple man and I like to keep things as uncomplicated as possible. While I tried your samples I didn't find a way to disable the 8 seconds right shift key thing or the 5 times shift key pressing. Maybe I overread it... Maybe its not possible... Maybe I only didn't understand the instructions... Anyway - I didn't like that window popping up at all. And I don't want to explain a user what do when this window pops up on his computer either. What me simple user needs is blocking several key combinations - that's all. And not on my Computer but on the program users computer and only while he's using my program. That means: Everything that can cause troubles - by chance or wrong usage or for whatever reason should be avoided. Start it with KeyboardGameLock(True) - okay. Add the Kombinations with a Command like KeyboardCombiAdd("Alt+Tab") inside the program. Kill it with KeyboardCombiKill("Alt+Tab") inside the program (no popup windows). And kill the complete thing with KeyboardGameLock(False) That's all. And the best would be, since its quite a tricky Program let it check by itself, if the calling Program is still a running task... if not, exit Keyboardlock immediate - so that the computer has no funny things (like not being able to use the start button with the mouse as happended here after a managed program crash) left... That's my view. I know what effort you put into it - since I fiddled around with KeyboardHook and TaskManager too long and had to postpone it since I had no error free result at all. Actually I had in mind to block disturbing Popup Windows as well - for instance: I don't mind to get a little message if friends enter MSN Messenger or when I get a notice that the AntiVirusProgram made an Update or that the Network is trying to restablished the connection with the internet. But that should not disturb fullscreen window games. Not by going back to Windows or not with endless flickering windows inside the fullscreen window. There are programs on the market that can block these things and the Key cominations and there are others that can't - but that shows it is possible. Hmmm - got carried away from the actual theme... |
| ||
| RaGR - the window pops up because Microsoft say it should! - Not BlackJumper. What BJ is trying to do is prevent that. BJ - it works just fine. Exactly what it says on the box - it prevents a full-screen app being alt-tabbed and therefore on some graphics cards causing an MAV. That alone was worth the money (;-}) but adding the sticky-keys catcher made it absolutely invaluable (since I use right-shift as a hold-down speed key). I feel my app is now rock-solid thanks to you. |
| ||
| Stickykeys really should not be touched by any app, other than Windows itself. I believe all that should be fiddled with are things that Windows does not give the average user controls to change. |
| ||
| Well default settings are restored after hotcakes, and how many people actually use the combonations? I think windows should have defaulted these shortcuts to off anyway :) I always turn them off now when i get a new machine or reinstall windows. |
| ||
| John B. You mean the 5 x Klick on Shift usually opens a Window in Windows? Not here, because that's disabled and Microsoft explains how to do it. And most Gamers do that anyway. But the Window pops up after 5 x Shift when the dll is running and that was the point what I didn't find positive. That's all. As I said: that I could not switch that off is maybe my fault because I only made a very superficial test. The conclusion is: What does it help me, when I prevent Alt Tab but am pushing the problem to 5 x Shift what I didn't have before... and Shift is often used for speeding up in combination with a forward key. And Games that use it usualy disable this "feature" and do not add it. |
| ||
| But the Window pops up after 5 x Shift when the dll is running and that was the point what I didn't find positive OK, that shouldn't happen... If you have StickyKeys/FilterKeys/Togglekeys shortcuts disabled {Not here, because that's disabled and Microsoft explains how to do it. And most Gamers do that anyway.} then this dll should not interfere. It was designed to only switch them off if they were left on by the user - and the user's original settings are then restored when you call SetStickyKeysState(false) or KeyboardGameLock(false). As a result there should be no annoying popups during the game (because you set KeyboardGameLock(true) or SetStickyKeysState(true) at the start) but you have not messed with their Windows setup once the game exits. I cannot check the code for this now as my development laptop is dying from a sickly fan and I am currently cloning the harddrive. I will look into this when I have access to the code again. @RaGR: You do realise that the 'demo' program was designed to show the difference between a program that is left to the user to deal with StickyKeys and one in which you take control by using the dll ?? When you toggle the function 'off' you may get intrusions - depending on the settings in the Accessibility Control Panel. Under normal circumstances this would only prevent intrusions - it isn't designed to introduce them :-) @RepeatUntil: I did the test with KeyHit(1) located at some other place in my code, and depending where it is located, sometimes it works as expected Are you using a KeyHit() test elsewhere in your code ? I think it should return the count for each different key (can't test just now... see above) but it might be that any call to KeyHit() 'resets' all other keys. Can anyone confirm this ? |
| ||
| No, that would make KeyHit() useless. =] But it could be possible that GetKey() is used somewhere? |
| ||
| In the meantime I found this: There's a DLL and some sourcecode. The whole article is quite interesting. And the thing works, too. Many additional stuff. Disable Desktop, Taskbar, Startbutton... run process in a new desktop etc... http://www.codetools.com/win32/AntonioWinLock.asp |
| ||
| I have to state quite clearly (for BlackJumper's sake) that I am having no problems running full-screen, with StickyKeys/FilterKeys/Togglekeys disabled. Certainly not getting a windows box popping up. I'm baffled by that, as the program appears to run flawlessly, even down to reinstating the system settings when my app quits. |
| ||
| That's nice, John - but the alternative link does not harm BlackJumper at all, doesn't it? King Dave started this thread because of the Alt+Tab thing - maybe he or other readers here want to try out different ways? This one seems to work different. And I didn't say better or worse. @BlackJumper - As I said - I didn't check it proper enough and didn't understand everything on glancing through it first time. Ok. I took a deeper look now. And must say - no popups - runs great. I don't know how it happened, but I always must have made the opposite of what was needed - that caused the wrong results. Anyway without my response I would have missed a very useful dll. Big thanks :-) |
| ||
| Thanks for clearing things up RaGR. In fact I used Antonio Feiajio's article as one of several references when I was upgrading my library (I think he is credited in the ReadMe). I guess we could all do with learning not to skim read... I saw the dialogs on that page and assumed that he was producing a 'tool' rather than a dll. Could have saved myself a bit of work ;-) |
   |