My Windows Phone 8 application checks network connectivity in OnNavigatedTo method. If the application finds out there's no network available, what should my program do?
If it was a desktop application, I would pop up a message box, saying "network is required", and exit the program.
I hear in WP exiting is not recommended; we don't often call Application.Current.Terminate().
Is there a way to suspend the application, return to the "desktop" and when users turned on Wifi, he can run my program and raises OnNavigatedTo again?
I know turning on Wifi automatically by the program or navigating to Setting page would be a good design. But I'm currently curious about suspending/minimizing the application.
No. There is no good way to programmatically suspend the app. You could hack it by launching another app, but that wouldn't be a very good user experience.
In your case I'd display a message that the app cannot continue without network access and wait for the network. The app isn't completely dead since the network may connect either on its own or by user action.
Flaky network connections are annoying enough without being compounded by the app exiting and users needing to restart it if they temporarily move in and out of a dead spot.
See How to detect network changes for Windows Phone 8
Related
We're writing a cross-platform C# "Xamarin" application; right now we're just targeting the iPad. The application has two features relevant to this question:
The app requires that the user authenticate to the app (in addition to logging onto the iPad)
The app connects to a remote device over Bluetooth
So the question becomes, what happens when the user switches to another app, which results in our app's OnSleep() being called. In OnSleep() we could immediately disconnect Bluetooth and log out the user, but that seems like poor usability, especially if they are just quickly checking some alarm that triggered or an instant message that came in.
For the sake of usability, we're thinking to have a 1-minute timeout; if the user does in fact pop out and quickly pop back into the app, we'd like things to simply continue on without any loss of communication or re-authentication.
If, in OnSleep(), I set up a timer using Xamarin.Forms.Device.StartTimer(), that timer does not fire while the app is "asleep".
What does it take to have a small background task/thread/process execute, even while the app is asleep? Something that simply waits 1 minute, and then shuts down the Bluetooth communication and sets a flag indicating re-authentication is needed?
I have a windows service created in c# and i want that no any other application can stop or kill that service process from task manager but i am unable to do that.
This can be done only with another service, that constantly checks your main service status and restars/reinstalls your service. That's a way many viruses work)
This isn't possible by design, see The arms race between programs and users (emphasis not mine).
Eventually you have to decide which side wins, and Windows has decided
to keep users in control of their own programs and data, and keep
administrators in control of their own computer. So users can kill any
process they want (given sufficient privileges), they can stop any
program from stealing focus, and they can delete any file they want
(again, given sufficient privileges).
I've created a service that runs as the Local System user. This service launches and monitors a Silverlight Out-of-browser application using native interop and the CreateProcessAsUser() method (to run it as the currently logged-in user, rather than Local System). I'm able to get a handle on the spawned Process and do things like Kill() it, however, I've become aware that the service is unable to get a handle to the main window of the child application because the child application is running as a different user. I'm running on Windows 7.
My end goal is to respond properly to when the Process stops responding (i.e. Process.Responding == false) so that I can kill the application and restart it. However, Process.Responding requires a handle to the main window of the process (Process.MainWindowHandle, to be exact), however, in this scenario, Process.MainWindowHandle always returns 0.
I'm stumped here. Is there any way for one user to get a window handle to a process running as another user in Win 7?
Thanks in advance for any and all help.
No, that's not possible. Windows Services are completely isolated from user-mode applications for security reasons. If you could get the handle to a window, you could manipulate and otherwise interact with that window, leaving open a huge security vulnerability.
More information is available here:
How can a Windows Service start a process when a Timer event is raised?
How can I run an EXE program from a Windows Service using C#?
windows service (allow service to interact with desktop)
Need suggestion on replacing Windows Service by invisible WinForm Application
Strictly speaking, what you're using the Windows Service for in the first place is bad design. It shouldn't be creating or launching any user-mode processes, or interacting with the user in any way. Remember that services run even when there is no user logged in! Thus, they shouldn't be starting applications.
A better solution is a simple background application, set to launch automatically when the user logs in. This background application could then launch the Silverlight application, monitor its state, and interact with it as necessary, because both would be running under the context of the same local user account. The effect is similar to a service, but without any of the drawbacks of isolation. The easiest way to do this in Visual Studio is to create a WinForms application (or possibly a WPF application, I have less experience in that area) that simply doesn't show any forms/windows.
I am developing a C# application (.Net 3.5, Win Forms) which is run on a server, and is accessed by Users using remote desktop. The application keeps freezing on seemingly random occasions on the remote machine (i.e. all GUI components turn to white, task manager reports the application to be not responding), but not when run locally (I'm not entirely sure about that, but failed to reproduce the freeze on my machine).
Has anyone experienced such behavior in his apps that are accessed remotely? What debugging strategy would you suggest? Do I need to consider something special when developing Win Forms applications that are accessed by remote desktop?
EDIT: some notes about the application and the freeze: The application does not recover from the freeze. Also, the freeze does not happen (or did not happen yet) during user interaction, but in between log ins to the remote machine. The application monitors a CFD solver, so it's doing things even when no one is using it.
UPDATE:
We did infact implement detailed logging, writing every function call to a file with a timestamp. Unfortunately, the results were not very conclusive. I.e. the last function call logged always returned correctly. Also, there were some background timers still running, even though the application appeared frozne (GUI completely white etc.). After some trouble we managed to have a look at a crashdump in WinDBG. On the system thread we found a call to OnUserPreferenceChanged() and further up to Invoke.WaitOne(). We can't say for sure yet, but it seems to be the issue decribed in these articles. As a quick fix, I installed a dummy handler to the event mentioned. I'll report how this works out.
UPDATE 2:
As it turns out, a Log In to a remote machine fires several OnUserPreferenceChanged() events. So it was indeed the suspected issue. The fix turned out to be not so easy though. I would have expected that an IllegalCrossReferenceException is thrown everytime a background thread tries to modify a control that was created on the system thread. This does not seem to be the case. I named my system thread and before each access to a control I asserted that the current thread name is the system thread's name. In various places this assertion failed (e.g. in a callback from a timer), but no exception was thrown. After using proper delegation at these places, the freezes stopped. The application runs nonstop for some weeks now and my users are happy again ;)
I do not think the freeze has anything to do with remote desktop. Adding logging was a good suggestion. I have a few suggestions, but without knowing the details of you application I can't get too specific.
The simplest suggestion I have is to check the memory useage and CPU usage in task manager when the freeze occurs.
If adding detailed logging is not an option, add just enough logging to know WHEN the application freezes. This could simply be a thread in the application which writes a timestamp to a file once a minute. Then you can see if there is any pattern in when it freezes, such as after a user has logged off, or when some of the data which you are monitoring changes, or at a certain time each day, or after being online for a certain amount of time.
A final and very hacky solution is to write a small watch dog application. This application's only job is to periodically check on the main application to make sure it is still responsive. How you dow this various drastically based on what your application does. If the watchdog sees the the main application has stopped, it can kill the thread for the main application and re-start it from the binaries.
if your using application streaming your server could be slowing the connection or waiting for packets that are dropping this can create this if your physical using windows remote desktop then there is your problem intense applications are not supposed to be run though remote desktop
AFAIK, there is no difference. Additionaly, I never experienced such a problem. I suggest, you try the following:
Extend your application with extended logging, to see what the users are doing when your application freezes
Check the network connection that is used to connect to the remote machine
Check the CPU usage during the freeze
If the freeze is for an extended amount of time, try to do the following:
Reproduce the freeze via remote desktop.
Go to the machine you just reproduced the freeze on and log in directly and see, whether the application is still freezed
If it is windows 10 version 1903 plus version. Then probably its the issue of windows. Please try the following settings:
Have read various blogs and concluded that the GPO has to force to use XDDM rather than WDDM. The issue is observed with windows 10 version 1903. Currently tested the workaround on machine NDT-61. It is working fine. Please practice the same for respective environment and let me know if some issue is faced.
Steps to Follow:
Open Group Policy Editor
Explore Administrative Templates
Explore Windows Components
Explore Remote Desktop Service
Click Remote Session Environment
Under Remote Session Environment Disable Use WDDM graphics display drive for Remote Desktop Connections
Note:
This policy setting lets you enable WDDM graphics display driver for Remote Desktop Connections.
If you enable or do not configure this policy setting, Remote Desktop Connections will use WDDM graphics display driver.
If you disable this policy setting, Remote Desktop Connections will NOT use WDDM graphics display driver. In this case, the Remote Desktop Connections will use XDDM graphics display driver.
For this change to take effect, you must restart Windows
Observation:
The policy settings are only available in windows 10 version 1903 and plus [ideally since when the issue started].
My aim is to create a login form where the login form comes when the system goes idle.This form contains username/ password and comment box where user have to provide reason for why system has goes to idle state.(ie if user left for a meeting or a break,he/she should provide details about it).this should be a window application which i managed to make.
Now i have to make this application run when ever system goes idle and the user can use only when login through this.So windows service is a option to run a program when the system starts and it can be managed well through service. So i made a window service which mange to run the application when the service start.
Now i have mange the window service to call this win app every time system goes idle. what possible ways can i make it work through window service.
I have already mention the above question in a previous post here
please help...
This is the kind of app that users hate with a passion, nobody likes a machine forcing them to do things. They'll try everything they can to get rid of it or sabotage it. Any data it collects is junk. Vista partly solved the problem, services cannot do this anymore.
Don't waste your time on it.