then using shell:startup is going to be the preferred method. If the script can be created as shell:startup and is going to be executed really briefly, such as making some network connections, etc. It really matters what you are going to do. If the script runs and is running while the user uses their computer, it will cause a slowdown on disk access. If the script is expected to perform a task and ends in less than a minute after startup, this is nothing to worry about. It can be configured to have multiple triggers, not just at startup, but also at a specific time, or even when the user locks or unlocks the computer.Ī script started by Task Scheduler will always create more impact on the system partition (disk read/write) as opposed to running the script manually or through shell:startup. The user cannot interact with the window in that case (this is typical for computer scripts, not user scripts, but a user script is also possible if you use a different user, such as SYSTEM. If configured properly, the script does not show any interactive window, so the user is not bothered by a flashy scripting window. This allows for a script to do something to files from a user that normally would be locked but aren't in this case, such as backups. The script can be configured to launch on startup for any user, not just yours, and even before the user is logged in, although it cannot do anything in the user's context then. Here are 4 things that are typical for using this method. The script will always open a visual window that the user can see and interact with.
It is not executed when another user logs in though, and neither is it executed at the logon screen. When you place a shortcut or script in shell:startup, the script is always executed when your user logs in.
Here are 3 things that are typical for using this method. Both are options but they have different applications.
0 kommentar(er)
