I have a problem with windows service. I'd like to his level run the program in a given situation. Every minute check a certain value and if the value is to adopt "truth" is to me the program starts. Only at the moment this does not work ...
The problem is that when debugging the code executes correctly, it displays my window, but the service is run normally nothing happens ...
Link to movies about this all:
https://youtu.be/GPv5dn92BGg
You need to jump through several hoops to launch interactive applications from a service. First, the service needs to be explicitly allowed to interact with the desktop. Then the service needs to specify the correct WindowStation for it to show on.
It may be simpler to just set your child application up as a scheduled task, as these can interact with the desktop for you
Related
The bundled XPC Service in my macOS application need to do some post processing work with files dumped by the parent app, which most probably can't be completed within the usage time of the application. So, Is there a way to make the XPC service keep running even after the user quits the main app?
You could install it as launch daemon (running in root context as long as computer is switched on) or as launch agent (running in user context as long as user is logged in).
It sounds like you should be using the WatchPaths or QueueDirectories feature of launchd.
WatchPaths starts the job whenever any of the paths being watched have changed
or
QueueDirectories starts your job whenever the given directories are non-empty, and it keeps your job running as long as those directories are not empty
Both of these are covered by Apple's launchd documentation.
I can successfully launch an app with
execl("/usr/bin/open", "open", "/Applications/Foo.app", 0);
But this doesn't work when I'm calling it inside Foo.app
I want my app to relaunch itself when it crashes and autoupdates.
Thanks!
open won't start a second instance of your app if one is already running, it will simply make it the active app.
You can start a second instance of your app by executing the app bundle's executable:
excel("/Applications/Foo.app/Contents/MacOS/Foo", ...
While not the recommended way to launching a Cocoa app, I've been assured by Apple engineers that this will work. But be warned, you now have two instances of your app running, sharing the same NSUserDefaults, and other resources, so expect some strange behavior (or immediately terminate the first app through exit()).
Having said that, this probably isn't want you want to do.
First, you can't "detect a crash and take some action" as—by definition—your app has crashed. There are packages out there that will detect a crash and log information about it; look to a solution like that to restart your app.
As for updates, again I'd steer you towards a third-party solution like Sparkle. It handles quitting your old app, replacing it, and then launching the new one in a sane manner.
Finally, you can register your app as a "user agent" with launchd so that it gets automatically restarted if it quits.
I dont know if this has to do with how the program is programmed or how it is set up or how it is started.
But I created a program in WPF and I would like to make sure that none of he regular users on the computer shut it down.
The regular users need to be able to interact with it but they should not be able to close it.
The correct approach would be to run the application as a service with permissions set by the administrator to not let the user manipulate the service. Otherwise you will run into trouble with user-initiated shutdown and with preventing the application from being terminated.
If it is the case that the OP wants to prevent visibility of the OS, creating a terminal like experience. The best way to do this is to create a shell replacement.
Then the user wouldn't see the OS as windows directly.
Is it possible to run handle.exe (from sysinternals) from a service (in windows7) without having to turn off UAC?
The service is a custom c-app that needs to find out which process is locking a file it tries to access and handle.exe seems to be a good way to solve it but i can't get it to work with UAC turned on. This app runs all the time so i can't have a UAC prompt while its running but its fine if it shows up at startup.
Handle.exe works fine from an admin commandprompt but fails when trying to run from a normal prompt.
I call handle.exe from CreateProcess() and get the output from pipes. I guess there should be a way to solve this but i can't figure it out. Setting up the service to log in from an admin account does not seem to work.
UAC does not affect services (it only affects interactive sessions) so that should work.
However, if you don't want to move your entire program into a service then there are better ways to do this which don't require creating, installing and managing a separate service process in addition to your main program.
If your program requires admin rights to work at all, and this isn't the only place it will require them, then you could flag your program (via its embedded manifest resource) as requiring administrator rights. It will then trigger one UAC prompt whenever it is run and be run with full admin rights, including the ability to run Handle.exe.
On the other hand, if this is the only place where your program needs admin rights, it may make sense to create a COM DLL which wraps your Handle.exe call (or any other admin work) so that you can use UAC to make elevated calls to that function from your non-elevated app. You will then trigger a UAC prompt each time you create (an elevated version of) that COM object. You can keep the COM object open as long as you want, and create it whenever you want, so when and how often the UAC prompt(s) appear are still up to you.
Both 1 & 2 are standard uses of UAC so any good documentation or tutorial on UAC will describe how to do them in detail.
You may want to look at the Win32 API method CreateProcessWithLogonW.
There is also an elevate VBS script here you may learn from: http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx
I'm not sure if this is technically a Kiosk, but it's basically the same idea. I have a program that runs full screen all the time from boot to shutdown to control a machine that the computer is hooked to.
Right now I just have a shortcut to the exe in the Startup folder so it starts when the system boots up and logs in. Is there any better way to do this? I'd really like the user to never see the Windows environment (just the windows loading progress bar on boot) if at all possible, but I'm guessing that's not possible.
Just thought I'd ask and see if there is a better way to do this than putting it in the startup folder?
The best option is to use Windows Embedded. This gives you much more control over the shell, and what is run and installed with the system.
If you have to do this with a consumer OS, you can try to bypass the login prompts to auto-login your user, and have your program setup in the registry to startup. Disable any other services you don't need. That will minimize the time the shell is displayed (but it's very difficult to remove it).