[education/rkward] rkward/rbackend: Fix detection of interrupted commands on Windows

Thomas Friedrichsmeier null at kde.org
Fri Jun 17 14:34:30 BST 2022


Git commit 4edde95af8411abaa41ccbe93fcc049b563dbdc2 by Thomas Friedrichsmeier.
Committed on 17/06/2022 at 13:34.
Pushed by tfry into branch 'master'.

Fix detection of interrupted commands on Windows

M  +4    -0    rkward/rbackend/rkrbackend.cpp

https://invent.kde.org/education/rkward/commit/4edde95af8411abaa41ccbe93fcc049b563dbdc2

diff --git a/rkward/rbackend/rkrbackend.cpp b/rkward/rbackend/rkrbackend.cpp
index b9faa368..fae358c6 100644
--- a/rkward/rbackend/rkrbackend.cpp
+++ b/rkward/rbackend/rkrbackend.cpp
@@ -902,7 +902,11 @@ void doError (const QString &callstring) {
 	if (RKRBackend::repl_status.interrupted) {
 		// it is unlikely, but possible, that an interrupt signal was received, but the current command failed for some other reason, before processing was actually interrupted. In this case, R_interrupts_pending if not yet cleared.
 		// NOTE: if R_interrupts_pending stops being exported one day, we might be able to use R_CheckUserInterrupt() inside an R_ToplevelExec() to find out, whether an interrupt was still pending.
+#ifdef Q_OS_WIN
+		if (!UserBreak) {
+#else
 		if (!R_interrupts_pending) {
+#endif
 			RKRBackend::repl_status.interrupted = false;
 			if (RKRBackend::repl_status.user_command_status != RKRBackend::RKReplStatus::ReplIterationKilled) {	// was interrupted only to step out of the repl iteration
 				QMutexLocker lock (&(RKRBackend::this_pointer->all_current_commands_mutex));


More information about the rkward-tracker mailing list