We have a small problem with our .net 4.0 wpf application. If the user locks his screen (windows) and a few seconds later unlock the screen (resume to the work), the application looks like this:
The user can not click on any control or do some thing. The curious thing is,
that it only appears if the user is on special tabs, where we use BeginInvoke
and work a lot with threading. I could not find any thing about this bug, besides that BeginInvoke can create those problems.
I also could not find any thing in the windows logs.
EDIT
I use multimonitor, if my application is black, removing the monitor cable an reconnecting it, the application continues to work.
The problem only seems to appear when using the wpf DataGrid. Switching from thsi grid to Telerik-Grid solve the problem, but i could not figure out which part cause the problem.
Related
I'm working on a Windows CE project and have run into a strange problem. When i display a messagebox the physical key stop working. The project relies solely on key input which work fine when changing focus between objects on the form. Because i can't slect an option from the message box, the application basically locks out.
I initially thought my keydown handler was to blame but i discovered the same issue regardless of the keydown handler (even in a new project it doesn't work)
I've been looking around online for information but the only thing i've come across involves changing messagebox buttons. The most prominent solution is to create your own messageboxes but it seems like a waste for what i need. Is there a more efficient way of solving this problem?
I've got an issue with the focus management in WinRT. The issue is specific for the application startup. Let me share the example of it:
If during the startup I change the focus (for instance I can start selecting some text in a browser), the runtime will decide that it doesn't need to show the application. The application is being started in a 'hidden mode'. It means that I do not see the UI, but I still can find it in process explorer.
So what I need here is to make the application be active in all possible cases. I tried to use several native functions such as ShowWindow, SetActiveWindow, SetForegroundWindow, but without any success.
I also noticed that any WinRT app is being started under WWAHOST.exe and mainwindowhandle is 0. The app shows up if I use 'Switch to' option in Process Explorer context menu.
WinRT applications are sandboxed and have very little control on the way the OS handles them, and almost no way to affect the behavior of other applications running on the same host. What I would suggest then is for you to design your application in such a way that it shows some UI as early as possible, then asynchronously you can load any other resources that your application may need.
I am writing an application in c# to lock or freeze all programs untill user enters a value in the app's textbox and clicks ok.
The purpose of the app would be to get people to enter their time.
As far as I know you can set it to top most but they can end the app with task manager so am stuck here..
formName.TopMost = true;
Any help would be appreciated
Yes, that's correct. The Windows operating system allows multiple programs to run at one time. What you're experiencing is entirely by design.
If I remember correctly, the TopMost property applies only to windows in your process, and as you mention, it's all quite irrelevant: the user can still kill your application using the Task Manager.
There's no legitimate way of getting around that. It's not a "limitation", it's a feature. Any app that prevents itself from being closed by the Task Manager is treading dangerously closely on the category of software that we call malware. Nothing good can come out of pursuits like this.
Relevant reading: The arms race between programs and users
Perhaps a good compromise solution is to make your window/form actually top-most and disable the Close button so that the user knows they shouldn't try and close it. This is almost always enough to stop a user that is not determined to end your application by any means necessary, and that's about all you should ever be concerned with.
See the sample code here for how to make your window/form always appear on top of other running applications by setting the WS_EX_TOPMOST flag or toggling HWND_TOPMOST.
I've also already written a detailed answer here about disabling the Close button the correct way by setting the CS_NOCLOSE class style.
I'm working on a rather big project with my team and after a while, we struck into a big problem.
Infact when we minimize the main window of the application, clicking on the taskbar to restore it results in a "bing" sound (the one that windows uses when you are trying to interact with a background window when a modal dialog is opened on it). I can't restore the window except if I press ENTER button (after obviusly clicking on it).
We are using XNA to render something inside a WindowsFormsHost component in our WPF application and the problem comes out when we change something that is not connected directly with wpf (something inside the rendering engine, so it works only with XNA).
I can't post any code because I don't own any rights of it and would be meaningless because the project is enough big.
So my question is: what are the things that can produce a problem like this one (unable to restore window sound) when you click on the taskbar?
At least I can understand where to search for this bug, because I don't even understand where I shall dirt my hands in.
Important notes: I'm using a splash screen and the problems come up when I do something on a second window (so not directly the main one) which is not modal
Thanks for any suggestion
We solved the problem by finding out that there is a bug with an external component that we used inside our application. Still I don't understand how this bug has been created, if someone has a better answer I'll mark it.
We have a C# .NET 3.5 UI client application that runs in a multiple monitor desktop environment (typically 4 screens) on Windows 7. Every so often, after running several of these applications, the screen stops redrawing.
Controls continue to be reactive to clicks or keypress and values can be updated programmatically, but the entire form is not redrawn to reflect any changes. For example buttons that are enabled/disabled based on state may be remain grayed out, but be reactive to clicks or vice versa. Buttons do not animate when clicked.
Workaround: minimizing and restoring the window appears to clear the problem. After this, the application begins to draw correctly.
The must frustrating aspect of this problem is that programmatically, everything appears to be running normally. No exceptions are caught in our logs. Nothing was visible in the system event logs. We have not found a way to detect this condition is happening yet.
Other miscellaneous aspects: logging uses log4net, server communication layer uses ZMQ
Update:
Calling form Invalidate() and Update() does not fix the problem.
When dragging the window between screens, it shows different values on each screen.
Minimize/restore still resolves the issue.
I can't be sure of anything without seeing the app and the code, but my best guess is someone calls .SuspendLayout() before a complicated update, and an exception (probably swallowed) prevents the code from ever reaching the corresponding .ResumeLayout(). To test this, try adding a button that calls .ResumeLayout() for the form.
It seems the solution is there:
1) http://blogs.msdn.com/b/alejacma/archive/2009/08/11/controls-won-t-get-resized-once-the-nesting-hierarchy-of-windows-exceeds-a-certain-depth-x64.aspx
2) http://support.microsoft.com/kb/2664641/en-us