System unstable when placing VS in shell:startup, how to ensure VS starts at appropriate time on reboot ? about virtualspace HOT 4 CLOSED

For most programs, there is no problem putting them in the shell:startup directory, because the programs do not interact with each other and the order in which they are started is not important.

But for VirtualSpace's window rules, this is not the case. There are many undefined conditions for calling Windows functions on a program whose main window is in some transitional state during startup. The windows in the Windows system are too diverse, which explains why Microsoft itself does not provide a built-in solution for window organization.

Concise solution:

Either put VirtualSpace in Windows' scheduled tasks and give a reasonable startup delay, or VirtualSpace itself provides the startup delay for window rules.

The failure retry mechanism you mentioned is only suitable for dealing with exceptions within the program itself, and failure retry due to external factors (unknown, uncontrollable) caused by errors is not a good solution, which will not only make the program itself unstable, but also affect the stability of other programs and even the system.

After all, this is a local program, not a C/S structure service that interacts through network protocols. Therefore, its stability, safety, and resource saving are the most important.

It can also answer your previous question about why you should use plug-in placement to provide features such as Cube3D and Updater.

This is because, in my opinion:

1. Modularity has many advantages, this is true for development, it is true for the stability of the program, and for users who do not need additional functions it is possible to not install plugins at all.

2. A local program should have no ability to access the network. If it weren't for the avoidance of frequent visits to websites to see if updates were available, the Updater plugin would not have been introduced into VirtualSpace at all.

from virtualspace.

Thanks for the comments, I will relegate VirtualSpace to start a few minutes after system startup to try to ensure a better user experience. Less advanced users may appreciate a "startup on system reboot" checkbox that delays itself a configurable amount of time or waits for idle time before launching (configurable ideally).

I'm also a little embarrassed to ask this question, but how exactly can I take advantage of the plugin behavior? I can see them installed, I can configure them, but I'm seeing no evidence they are actually running. Do individual plugins have to be enabled? What evidence can I see that they are working as intended ? Confused.

from virtualspace.

I ended up creating a Windows 10 Task Scheduler task with the following properties:

• Run only when user is logged on
• Triggers : At log on
• Actions : Start a program VirtualSpace
• Conditions : Start the task only if the computer is idle for: 3 minutes, wait for idle for 15 minutes
• Settings : Allow task to be run on demand, if the task fails, restart every 10 minutes up to 3 times, If the running task does not end when requested force it to stop, If the task is already running, Stop the existing instance.

I'm not sure if VirtualSpace will come up minimized on startup, I'll report back when I try this out on my next reboot.

from virtualspace.

Thank you for the quick turnaround, it is much appreciated !

from virtualspace.