You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If a build command or run command results in the cmd command 'pause' being called (on Windows), the build output will be stuck as the command is waiting for user input it will never get. The 'Build: Kill Running Command' command does not seem able to kill the process in this case.
For example, putting 'pause' in a .bat file and setting that .bat file as the run command will cause this behaviour.
Similarly, a C/C++ program which calls system("pause"); will cause the same behaviour if it is set as the run command.
It is worth pointing out that a C/C++ program calling _getch() (a function which waits for and returns the keycode of the next key entered by the user) will similarly freeze the build output, but will yield to 'Build: Kill Running Command'.
Attempting to switch workspaces while the build window is stuck causes Focus to freeze, and so the only way to restore the ability to build after it gets stuck is to restart Focus.
As far as I can tell the build timeout setting does not have any effect in this case.
To Reproduce
Steps to reproduce the behavior:
Make a .bat file containing the cmd command 'pause'
Make a project and make a build command that calls the .bat file
Run the build command.
Expected behavior
'Build: Kill Running Command' successfully forces the build to stop.
If you try to switch workspaces while the build is stuck on 'pause', the editor should give the user some prompt asking them what to do as the build is still in progress, or forcibly stop the build.
Probably the build timeout should also correctly stop the build after the given number of seconds in this case.
OS: Windows 10
Focus Version: 0.3.0 (sorry! I guess I forgot to update it on my home PC. Might check if this bug still exists on 0.3.1 later, but I suspect it shouldn't make a difference as the bug is pretty specific)
The text was updated successfully, but these errors were encountered:
On 0.3.2 the bug doesn't happen with the .bat script, but my C++ program which calls system("pause"); still refuses to shut down when I use kill running command. I'd guess this might be to do with system() spawning a new process?
Describe the bug
If a build command or run command results in the cmd command 'pause' being called (on Windows), the build output will be stuck as the command is waiting for user input it will never get. The 'Build: Kill Running Command' command does not seem able to kill the process in this case.
For example, putting 'pause' in a .bat file and setting that .bat file as the run command will cause this behaviour.
Similarly, a C/C++ program which calls system("pause"); will cause the same behaviour if it is set as the run command.
It is worth pointing out that a C/C++ program calling _getch() (a function which waits for and returns the keycode of the next key entered by the user) will similarly freeze the build output, but will yield to 'Build: Kill Running Command'.
Attempting to switch workspaces while the build window is stuck causes Focus to freeze, and so the only way to restore the ability to build after it gets stuck is to restart Focus.
As far as I can tell the build timeout setting does not have any effect in this case.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
'Build: Kill Running Command' successfully forces the build to stop.
If you try to switch workspaces while the build is stuck on 'pause', the editor should give the user some prompt asking them what to do as the build is still in progress, or forcibly stop the build.
Probably the build timeout should also correctly stop the build after the given number of seconds in this case.
OS: Windows 10
Focus Version: 0.3.0 (sorry! I guess I forgot to update it on my home PC. Might check if this bug still exists on 0.3.1 later, but I suspect it shouldn't make a difference as the bug is pretty specific)
The text was updated successfully, but these errors were encountered: