Fast Macro code, how to interrupt, stop?

[PhranceQueTara]

How to interrupt running Basic Macro code, when the main IDE-window does not have focus?
The following example is rather silly, but illustrates my question.
When running the script below from within the IDE by clicking the run button in the menu, then focus goes to the Msgbox, and “pretty much” stays there.

Sub EndlessMsgBox
	Do Until False
		Msgbox("Hello World")
	Loop
End Sub

These Interrupt-Attempts did not work:

• Ctrl+Shif+Q does not work
• Shift+F5 does not work
• None of the IDE buttons nor pulldowns work, because don’t have focus.
• Can’t exit IDE, because because doesn’t have focus.

Any insight is appreciated.
(LO 7.0.2.2, Windows 10)

[PJTraill]

A very reasonable question; I have been wondering the same; how to get into the debugger under various conditions, including your situation, my code detecting an inconsistency, and that the run-time reporting an error. In all these cases I want to see the call stack before execution stops.

Of course I would also like to be able to walk up and down the call stack, examining variables local to each level.

[PhranceQueTara]

I figured out a somewhat clumsy way, don’t know why or how works:

• Go into the main LO_Base window, and click Menu/Tool/Macro/Run Macrocs…
• Then select the exact same Macro you want to interrupt and click the [Run] button
• Go back into the IDE-window
• Now, after clicking the [OK] button inside the Msgbox, code halts and lets me stop it.

I’m sure there’s a more elegant way than that. LMK.

[Ratslinger]

Hello,

You can set a breakpoint (circle with dot left of code line) then be able to step or cancel:

See → LibreOffice Basic IDE

and → Integrated Development Environment (IDE)

[PhranceQueTara]

Sure, I agree, break-points are great to use during debug, when planning to set them before running code, and when setting them upfront (basically when anticipating code issues).

But how to interrupt already running code, if the focus is not passed back to the IDE? (or, as in my silly example, if focus is only passed back to the IDE for a brief moment, not long enough for manual interrupts).

Assumptions:

• No break-points were set
• No other escape mechanisms added to the code itself

I could imagine that somewhere within LO exists some sort of an interrupt handler, where maybe custom keyboard shortcuts could be tied to setting specific interrupt flags, or similar. If the keyboard shortcut Ctrl+Shift+Q (or equivalent) was intended to do so, maybe its interrupt “rights” could somehow be “elevated or extended” to running code (in this particular example: the Msgbox routine).

[PhranceQueTara]

I tried my example again.

This time neither the LO-Base-main-window, nor the IDE-window would take focus, so could not access any IDE or LO functions.

Probably could have killed it via Windows Task Manager [Ctrl+Alt+Del], but to get out of the running code, I did this:

• Open a completely different LO_Base
• Click Menu/Tool/Macro/Run Macrocs…
• Select under [Library]: LibreOffice Macros/Access2Base/Methods/
• Select under [Macro Name]: _Refresh
• Click the [Run] button (this will throw an error, but don’t care)
• Go back into the IDE-window

Now, after clicking the [OK] button inside the Msgbox, code halts and lets me stop it.

[Ratslinger]

Your conditions are not reasonable. In this case simply kill the process & fix the terrible code.

[PhranceQueTara]

Yes, indeed possible, as indicated in the example below, but my question still is:

How to interrupt running Basic Macro code, when the main IDE-window does not have focus?

All answers I could find so far (in other threads & this thread) require that one can access the functions of the IDE-window. But what to do if one finds themselves in a situation, where one does not have access to the IDE-functions, because code is putting focus one other objects (= Msgbox in this case).

How to interrupt the code then? In the old VBA days I tend to remember that it was possible with a full keyboard to exit out of code with [Ctrl]+[Pause/Break], or similar.

Below is my quick example on how to programmatically break out, but again, only possible while one has access to the IDE-functions.

Sub EndlessMsgBoxWithCancel
	Do Until False
		If Msgbox( "Continue?", MB_OKCANCEL ) = IDCANCEL Then Stop
	Loop
End Sub

[PJTraill]

@Ratslinger

Your conditions are not reasonable. In this case simply kill the process & fix the terrible code.

I am sorry to say that this is mildly offensive and highly unhelpful. In my experience of debugging it has over and again been very useful to debug the process when an error occurs. “Fix the terrible code” requires finding out what is terrible about it, that is easiest done when an error occurs, and the debugger is the tool for that. (If one knew why the code was terrible, than one presumably would not be testing it, but indeed fixing it.)

I fully understand that an IDE produced by a volunteer project may sometimes not offer all the useful functions that others do, and am grateful for what we have. But at the same time we have to admit that there are deficiencies and share any workarounds and good hacks that we may come up with.

[JohnSUN]

@PhranceQueTara

Below is my quick example on how to programmatically break out, but again, only possible while one has access to the IDE-functions.

Sub EndlessMsgBoxWithCancel
	Do Until False
		If Msgbox( "Continue?", MB_OKCANCEL ) = IDCANCEL Then Stop
	Loop
End Sub

Try Print "Continue?" instead If MsgBox() - written shorter, but does the same thing.

[PJTraill]

This is answered at 70598 – Basic IDE - no way to stop a macro in an infinite loop (referred to in How does one interrupt a running macro? - #3 by jimk).

• Open another document, if there is none open.
• In that other document, press Ctrl-Alt-Q.
• A message box appears, saying “The macro running has been interrupted”.
• Dismiss that message box.
• Dismiss the message box your macro is showing.
• Observe that your macro is indeed no longer running.

Unfortunately this stops rather than interrupting and breaking into the running macro, so you cannot observe the programme state that lead to the problems. My solution to that, in a spreadsheet, is a set of trace functions, which write messages to a specified sheet, providing me with a debugging trace (and timings).