When I run my application, do some work on it and then change the keyboard input language (via alt+shift or task bar), my C#, .net-4 application became completely unresponsive. meaning mouse click does not effects the window and the window itself cannot be moved. That been said, no hour glass is been displayed and the process does not go into the "Application do not respond" state, i.e it will not be shutdown by the operation system (windows 7).
I have encountered a problem like this once when I had (in a different application) a deadlock between the UI thread and another thread. I can assure you this is not the case here, I have been debugging this phenomenon from different angles and no thread in the system is at a join whit or sleep state. not only that but the UI main thread is at the UI (normal exsepting messages from the operation system).
to summerise:
My application is a C# 4 application running on the .net 4 framework.
The application runs on windows 7 (we have no xp computers to try it on).
When the input languge changes the application became unresponsive for the user, but windows does not treat it as such and does not make an attempt to force close it.
Did anybody encountered a problem like this before? I could realy use a starting direction on this one...
Related
I have a winforms app that is capable of showing forms, and even upon closing the last visible form will continue to run in the background - and I make use of a notify tray (system tray) icon to show that it is running.
I have code in place to prevent right click\Exit on this icon if any forms are visible. I check that
System.Windows.Forms.Application.OpenForms > 0
and while this seems to work for the most part, it may not be reliably (testing this application on other machines seems to yield unexpected results). Is there a way to check if a winforms app is running as a background process (as opposed to counting the number of open forms)?
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.
I have an application written in C# and running on Windows Mobile 5. It currently takes several seconds to load all of the assemblies. During that time the wait cursor spins on top of the screen. I would like to show a splash screen with a progress bar instead. How can I prevent the cursor from being displayed?
You can't. The CF execution engine (i.e. mscoree) itself makes the call to set the wait cursor, and this happens before it even starts JITting code. There's no way to hook into that and no registry entry (known or undocumented) that can turn the behavior off.
I am now developing an application on Windows Mobile 6.5 with .Net Compact Framework 3.5 using C#. There is a function in the program that I use it to update the location information periodically from server side, but if I keep running this computation, it would cost too much energe. For this reason, I want to run it in background and I try to use BackgroundWorker to do this and it works well.
The problem I have now is that I can't minimize the program so that I have to keep the main form of the program run in foreground even if it's not doing anything and this is very inconvinence for a user. However, when I close the program, the BackgroundWorker will also be closed.
Is there any method to keep the update process running (somewhere in memory or so) when I close the program? and then can restore the information when I restart the program?
How about creating a Service instead of a background worker?
If your Form closes, then Application.Run (probably called over in Program.Main) returns and the process' primary thread exits, causing the application to terminate.
The solution, then, is don't close the Form, simply Hide it. By default the "MinimizeBox" property for your Form should have been true and it should have an [X] in the upper right corner. Clicking this minimizes the Form and will not exit your application.
The other option in some cases is to not have a Form at all. The challenge here is that the CF doesn't have any Application.Run overload that doesn't accept in a Form (like the desktop framework does). The Smart Device Framework does provide one if you want to go that route.
I have not used the .NETCF 3.5. However in the previous version on .NETCF 1.0/2.0 I observed that even if you close the application using (X) button, it just goes to background but remain in the memory.
If that is the case with .NETCF 3.5 as well then I think you do not need to anything here. The background worked will be running even if you close the application.
I Hope this will help you.
I have a graphical control that is multithreaded.
Until now it worked fine, but I just noticed that whenever I'm on my application showing this control the following happens: if I lock and unlock my workstation, it freezes, like if it were in some kind of infinite loop.
Even stranger, this bug occurs only when I'm not launching the app from Visual Studio, and not attached to it.
Does anyone have a clue on what's happening?
For instance, if I attach Visual Studio to the already freezed app, can I see which lines of code my threads are executing?
Any help will be appreciated!
We recently had (for about a year and a half ;) this same problem. It also triggers sometimes when IE flushes caches, when you change colors of you theme. etc.
The problem was that we had a splash screen that had its window created on one thread and then it was shown (ShowDialog()) within other thread. Once we moved the window creation to the same thread that actually shows it, it resumed. There was also some changes with .Dispose():ng the splash window, and they could also have had an effect.
Microsoft has an article about this and they basically suggest to run their Spy++ program and look at your program when it's hung. There is a "Windows" -window, search for your application and look for any windows that should not be there. They possibly have a windows message pump active/attached but it is not pumping. The "change" message does not get handled and all .NET windows stall -> hang.
just attach VS to the frozen app and hit Pause button, VS will show executing code.