Why can't I step on when placing a Breakpoint in a method

55 views
Skip to first unread message

Marten Feldtmann

unread,
Oct 20, 2020, 6:33:20 AM10/20/20
to VA Smalltalk

This is perhaps a user error I always walk in and I do not know why.

I place a statement "self halt" into a method and the debugger pops up, when hitting this statement.

But I can not resume my code, I can not trace or step. I have to change the method and then I can restart this method and step through it.

That is really strange, but I do not know why this is. Any idea ?

Richard Sargent

unread,
Oct 20, 2020, 12:33:51 PM10/20/20
to VA Smalltalk
It's no help to say that I have never seen this behaviour. However, tell us more about what you do see. You write "cannot", but don't say whether the buttons to step are disabled or whether they are enabled but pressing them produces no result.


Marten Feldtmann

unread,
Oct 20, 2020, 1:11:35 PM10/20/20
to VA Smalltalk
Ok, I can describe it much better and this is also perhaps the answer: It's a UI, where an ExecLongOperation with a progress-dialog is executed and during this work a break-point is hit and you can't trace further on ...

Below is a video (which can not be shown by Linux Firefox) showing this effect and I do not know to handle it:

Richard Sargent

unread,
Oct 20, 2020, 1:36:12 PM10/20/20
to VA Smalltalk
On Tuesday, October 20, 2020 at 10:11:35 AM UTC-7, Marten Feldtmann wrote:
Ok, I can describe it much better and this is also perhaps the answer: It's a UI, where an ExecLongOperation with a progress-dialog is executed and during this work a break-point is hit and you can't trace further on ...

Oh! I had forgotten how much inconvenience *that* caused.

If you look in EtWindow>>#execLongOperation:message:allowCancel:showProgress:, you will see that there is a class variable that may allow you to work around the Long Operation semantics/antics. You can also see that it captures user breaks and who knows what else.

The class variable has corresponding accessor methods: EtWindow class>>#execLongOperationsInBackground and #execLongOperationsInBackground:. As I read the code, it looks like setting it to false will run it as a "short operation" and probably(?) bypass the issue you are encountering.

Richard Sargent

unread,
Oct 20, 2020, 1:37:12 PM10/20/20
to VA Smalltalk
I have to clarify that I was looking in a 9.2 image. I don't know in which version this bypass functionality was introduced.
Reply all
Reply to author
Forward
0 new messages