I am developing a simple chat application which works in LAN. I have a problem in ALt+Tab.
When I open 2 applications (One is mine and another one say Firefox), now it switches properly between two windows when I press Alt+Tab.
Now I will minimize firefox. So now my app is the only one in foreground. Now if I press Alt+Tab, firefox comes foreground which is not expected (or I dont expect).
How to make Alt+Tab not work when all windows are in minimized state ?
I am using vb.net but c# is also OK for me and for example I have given firefox; there may be n number of windows in minimized state.
Please help me.
Pressing ALT + TAB in Windows (or other OS) is supposed to switch between every active application that is running and has a top-level Window. So the behavior you are describing is actually working the way it is supposed to.
More on Wikipedia about that.
However, it is possible to hack this behavior by capturing the ALt-Tab event. It is actually used by several remote control application so they can transmit commands from one computer to another.
Here is a start up guide, but beware that you get into Windows weird APIs and low-level functionnality. Use at your own risk...
Related
I have an application that uses a low level keyboard hook to capture the user's choice of keyboard shortcuts at a global level to activate the application's main window. Because I want to allow sometimes "odd" shortcuts, like F12 or Ctrl+Ctrl (double tap), I use the hook instead of the RegisterHotkey API function. Until Windows 8, this feature worked great. In Windows 8, some windows prevent my application from receiving the event but only while those windows are in the foreground. The Windows 8 Task Manager is one such offender.
Note that, because the problem only occurs while the offending window is in the foreground, I know that my hook is still registered with the system, just temporarily not reaching my application.
The current code base is C# Framework 4.0; however, I tested the previous code base, which was unmanaged C++ and the problem is the same.
Version of Windows is 8.1 Pro with Media Center
One thing I have not yet tried is moving the hook procedure to a separate DLL. I think I read that the low level keyboard hook procedure must be in a DLL but I have never found this to be true. Before I go to the trouble of trying that, I wanted to ask whether I am missing something easier and more obvious.
Now I understand. Although my application runs under a Windows account that is in the Administrators group, it needs to be launched with "Run as Administrator" in order to avoid being blocked by UIPI.
The solution, at least for me, is to ask a Windows 8 end user to launch my application as Administrator, if s/he wants to use "fancy" global keyboard shortcuts like the ones I mention in the question. (I also allow the user to use "simple" shortcuts, which are implemented with RegisterHotkey() instead of with WH_KEYBOARD_LL and therefore do not suffer from UIPI.)
I'm writing a .NET 4.0 application that simply accepts input into a TextBox, processes it and then sends it off to a database. This app is intended to work with USB barcode scanners.
I have a requirement to ensure that the input from these barcode scans is processed by this app. I have been asked to ensure that this app stays activated and focused at all times as the laptop it will reside on has no other requirements other than to power and accept input from a USB barcode scanner.
I managed to achieve this myself by using a System.Windows.Forms.Timer that calls this.Activate() on a set interval, or better yet;
protected override void OnDeactivate(EventArgs e)
{
BeginInvoke((Action)this.Activate);
base.OnDeactivate(e);
}
Whilst these methods work fine on my Windows 8.1 Development machine, I can't get this same code to work on a Windows 7 OS (I've tried numerous boxes as well as VMs). For the Win7 machines I can see that this code is executed fine, but I just cannot get my app to Activate again.
Could anyone please advise as to why I'm seeing this behaviour?
Many thanks!
Windows only permits the application that owns the foreground window to bring another window into the foreground (either one of its own or belonging to another application). A background application can't bring itself into the foreground. This is a deliberate design choice (introduced circa Windows 98, as I recall) to prevent background applications from interrupting what the user is doing - particularly to ensure that keyboard input goes to the right place and doesn't accidentally fire actions that the user hadn't intended.
This constraint is documented in the SetForegroundWindow documentation:
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
• The process is the foreground process.
• The process was started by the foreground process.
• The process received the last input event.
• There is no foreground process.
• The process is being debugged.
• The foreground process is not a Modern Application or the Start Screen.
• The foreground is not locked (see LockSetForegroundWindow).
• The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
• No menus are active.
Source: SetForegroundWindow function (Windows)
If you need to be sure that input from a barcode scanner goes into a particular application, you should look into keyboard hooks, if the scanner is configured for keyboard emulation, or whether the scanner supports another API to allow direct control.
For example, the scanner may support the National Retail Federation's UnifiedPOS standard. Microsoft have provided a library, POS for .NET, which allows UnifiedPOS devices to be controlled from .NET.
That's an illegal action. You're stealing control from the user, which is forbidden in the desktop ecosystem. The user should always be the one in control. Windows Vista+ started paying a lot more attention to things like this.
The proper thing the OS is supposed to do is notify the user you want his attention (e.g. flashing the window in the taskbar), it must not actually activate your window. Every time the OS allows you to steal control from the user, it's considered to be a bug, and usually must be fixed.
Maybe you want to replace the default Windows shell instead? That will allow you to simply have just one application running anyway, and when it's closed, it will restart the machine...
Barcode scanners typically transfer their data as if some user would have typed it by using keyboard. This lead to a false assumption that you need to have focus and active window all the time.
However, you could use technique from stone age called keylogging (usually with the word trojan in front). This is achieved by setting keyboard hooks in windows based system. Then your application can have all the input.
It's done by using SetWindowsHookEx. I still have windows XP software which uses hooks and it seems to work under Window 8.
The problem to determine when it's a barcode scanner and when user is typing password into login form of another application I leave at your disposal =P.
Say I have started application on Windows (created in WPF for .NET in case that would help), that opens some windows/panels and just runs in a background. User don't want to interact with it constantly, however once in a while needs to urgently execute some actions in it.
Is it possible to bind some key shortcut e.g. alt+key to running application, so on hitting it app gets focus? It doesn't necessarily need to be brought to front, altough that would be nice as well.
"a hotkey that works out of your application" is this what you want?
if so, you need global hotkey that i can reference to!
(Sorry i didn't have enough reputation for commenting!)
I think I found sort of semi-solution, that doesn't need any coding or changing any system settings, but only:
1) keyboard with Windows key
2) possibly forcing user to re-arrange icons on his task bar (or pin my application as one of first 9 applications on his taskbar)
pressing WinKey+digit brings up digit'th application from the taskbar. Pressing it again hides it.
This works for Windows 7.
Obiously doing this way is a bit lame and not customizable at all, but it's always something... Still happy to find better way if there exists such.
I have a .NET application (C#, WinForms) application running on Windows XP. If i minimize my application, and have several other windows minimized to the taskbar, and click on my application (in the taskbar) then often i see the taskbar "icon" blink but my application fails to "restore" its window. Any suggestions to what might cause this? Any hints on how to check if my application is not getting an event from the mouse-click.
UPDATE: Could anybody give an example of, how to output any incoming events to an application. Something that allows me to e.g. print the received events using Console.Writeline() to see, if my application gets an event when I click on the taskbar?
http://www.catch22.net/software/winspy-17
I venture to guess that your app will become in focus.
AFAIK this should not have anything to do with your application. Is there any other application running which always remains on top?
You dont handle maximising and minimising to and from the taskbar in your app. That is to say you dont have to. Windows deals with this and so this would appear to be in no way related to your app not handling an event, rather Windows doing something (or not doing something).
Currently our software is running on AIX Unix machines, but we use Windows boxes running Exceed to display the UI in X-windows. I'm writing a Windows application ( modernizing the UI in C# ), but some of the legacy windows still need to be displayed in Exceed. When a user clicks a button on my windows application, it sends a message to the Unix server which displays the X-window. My problem is that these X-windows are not getting focus, so they are popping up BEHIND all of my .NET windows/forms.
A user of this software can easily have 5+ windows forms open at any given time, so it is a big inconvenience if every time they want to display a legacy X-window, they have to minimise all of the .NET windows. What is the best way for me to solve this? Is there a way for me to give Exceed focus so that it brings the X-window to the top? I tried using Application.OpenForms, but calling .SendToBack() on each form didn't help me.
If the pop-up windows are coming from a process other than the Windows app which you're creating, you'll probably need to resort to a hack. Microsoft put code into WinXP to prevent apps from being able to throw their windows in front of everything, unless it's part of the app the user is working on. To do this, you need to monkey with the ForegroundLockTimeout registry value, and the Windows APIs to pull a window to the front.
More info:
http://social.msdn.microsoft.com/forums/en-US/winforms/thread/54826e98-9faa-4457-ba1d-b645af88170b/ (The last entry contains the conclusion, but you'll need to read some of the previous entries. I also suggest you set the ForegroundLockTimeout to zero, do the switch, then set ForegroundLockTimeout back to its previous value.)