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.
Related
What I need is to provide an exit confirmation dialog for my mobile app.
The dialog is to appear when users taps the Back button on their phones. I know two options i.e.
"Press back again if you really wish to exit" type of message.
"Do you really wish to exit + Yes/No" dialog.
I am exploring the second variant.
The problem I see primarily concerns the windows store apps.
If I show it and give user time to decide than I have already cancelled the default behavior.
For windows store app it is Windows.Phone.UI.Input.HardwareButtons.BackPressed i.e. I've set the Windows.Phone.UI.Input.BackPressedEventArgs.Handled to true.
What do I do if user clicks Yes i.e. confirms his intent to exit the app?
I've read the Metro App can no longer be programmatically killed and do understand that programmatically closing the windows store app is considered "unacceptable". Does it mean that such an exit confirmation dialog is banned for windows platform?
What about Android? Is it ok there to exit the app programmatically?
Formally Windows Store Policy does not allow such behavior:
Where applicable, pressing the back button should take the user to a previous page/dialog. If the user presses the back button on the first page of the app, then the app terminates (unless it is allowed to run in the background).
So you might be lucky to pass certification, but it is definitely not recommended behavior.
For "testing purposes" there are two methods exposed in API to programmatically exit application:
High-level Application.Current.Exit()
Low-level CoreApplication.Exit()
Technically you can use one of these methods to force application to close after user confirmed to exit. But there is no guarantee that you will pass certification.
For Android there are also guidelines. In particular the Core App Quality guide says that
App does not crash, force close, freeze, or otherwise function abnormally on any targeted device.
There are various discussion on Stack Overflow on how to correctly close Android app (example).
From my experience such apps do path certification, but Play team may choose to not promote them as they don't follow official design guidelines.
You could by using the onBackPressed callback method and showing a dialog, but as Jason said, it is a bad practice on Android too.
Let me explain why.
The OS has a PackageManager which manages every apps on the device. Apps have a priority level. That's why the phone app opens when it receives a call and yours get paused (in background). If the active app with the highest priority level needs memory or if your device encounter any problems, it can destroy your activities and then close your app automatically.
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...
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 am a developer of console-based server software, that occasionally seems to lock up on input until Enter is pressed. I suspect this is XOFF/XON (Ctrl-S/Ctrl-Q flow control) handling in System.Console windows.
Is it possible (using .NET calls or Win32 API functions) to disable XOFF/XON flow control processing in my C#/.NET application that uses System.Console for output and input commands? (This also affects other system consoles such as CMD.EXE windows, but I don't care about those cases.) My app is server software; don't ever want a key that freezes the console, especially one that can be triggered accidentally as this appears to be.
Somehow I believe my server app's console is getting a Ctrl-S on input, or perhaps the Ctrl qualifier is thought to be pressed when S is entered. Console locks up until I hit Enter. (I'm thinking Ctrl-Q would have also released it but haven't had another opportunity to test that yet.)
My processes are C# servers on .NET, and these are consoles using System.Console.ReadLine() on Hyper-V VMs running Windows Server.
This may be critical to the problem cause: I am connecting to the Hyper-V host via Remote Desktop (RDP). One thought is the RDP disconnect is losing a Ctrl key up and then the next 'S' that is input (by our command automation software) locks the terminal. We are eventually replacing that with network-based command input, but in the meantime we are fighting with this problem, which requires manual intervention by staff to get the server running again.
Further info: I tried the following, in case it was Quick Edit mode being triggered by an RDP session from a tablet, but this did not stop the lockups:
GetConsoleMode(handle, out oldmode);
int newmode = oldmode;
newmode |= ENABLE_EXTENDED_FLAGS; // required to disable the next two
newmode &= ~ENABLE_QUICK_EDIT_MODE; // force this OFF
newmode &= ~ENABLE_MOUSE_INPUT; // force this OFF
newmode &= ~ENABLE_WINDOW_INPUT; // force this OFF
newmode |= ENABLE_INSERT_MODE; // force this ON
if (newmode != oldmode)
{
SetConsoleMode(handle, newmode);
I think it is safe to conclude after all these years without a solution or anything to contradict or workaround the issue, that disabling flow control on a standard C# console app on Windows is is not possible, and that this leaves console apps that accept input (such as Ctrl-C or Ctrl-Break) open to hangs caused by XOFF characters. This means it is not suitable for most servers.
we would like to build a screensaver that shows the desktop and the running applications but prevents user input by showing the login screen. The idea was to build a windows app with no window or a transparent window. However, as soon as the screensaver gets activated the desktop and all applications are hidden from the screen.
Is it possible to start the screensaver without hiding the desktop?
Thx,
bja
Is it possible for you to implement this as something other than a screensaver? I'm assuming that the Windows API does have a method that allows you to tell how long the computer has been idle (otherwise, how does the stuff that manages screensavers do it?), so if you use that you could just set up your application such that it's continuously running as a background process, and will pop up a modal dialog box (or your idea of a transparent window) or something that prompts for the user's login info when the computer has been idle for a certain amount of time.
Why can't you just grab an image of the screen when the SS kicks off. Then use that as the backdrop of your SS.
Vista has a bubbles screen saver that just starts putting bubbles on the screen. Not sure how they do it.
You are better off just creating a full-screen application with a transparent window that starts up on a timer like a screensaver. The screensaver functionality while similar to what you are doing, functions much differently.
As an alternative suggestion, you could always use a service (or background app) to gather the information you want these monitoring tools to display, or even just to grab periodic screenshots of the (hidden) desktop, and then have your screensaver query that app to get the data it needs to display.
That way, you get the benefit (the secure desktop, the usual Windows login sequence, etc.) of a screensaver, but still get to display what you need to.