I'd like to schedule a task that is a program that launches another program. The other program is a Windows.Form application.
Is it possible to programmatically interact with a Windows.Form application on a non-interactive desktop session?
Specifically, because I know this sounds very odd, I'd like to launch SpaceSniffer or something similar, and provide some interaction with it.
No, well it's not a good idea, anyway. Call a program with an API or a command line interface.
Related
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
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.
I have a process (say, for example, MyProcessA), hooked an exe and injected my dll (MyDll.dll) into the process space of MyProcessA, so even if it's gonna create n number of child processes it will be process hooked as well. I have no problem in hooking and injecting the dll into the process. I have hooked all file and process dependant functions, but somehow I am not able to achieve complete hook of any setup (any application setup). I suspect if am missing any process related APIs or it might be some UAC problem, currently I am using CreateProcess(A&W), NtCreateProcess, ShellExecute(A&W). What could be the problem?
I suspect that the answer is related to the "Windows Installer Service". I'm guessing that your hooks wouldn't catch any interactions with a service, which even if launched as a result of FireFox's setup is going to be created by a different System process. I haven't had much experience with Windows Installer, but the documentation here should have more details than you could possibly wish for, given the time to find it.
UAC might also cause you issues, but you should be able to rule that out by launching the hooking code with administrative privileges to start with.
Is this research for uni? Either way good luck, it sounds like an interesting problem.
WPF launches certain method which calls external exe and waits , and then accesses a file which was an output of external exe. Assuming I would build this application with a consideration of porting to Silverlight 4 later what should I do ?
In order to do this you would need to go through Silverlight's COM automation. I'm sure there's some out-of-process COM server that you could use to start a process. But at that point you've already
limited your application to Windows
require full trust
will only work in "out of browser" mode
At that point, you really gotta ask whether or not it makes any sense to port to Silverlight. WPF is particularly suitable for the above scenarios. You can use ClickOnce to achieve a similar (actually, superior) client update experience and you won't have to jump through hoops to do something as simple as spawning an external process.
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).