It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need). Not sure how you get an icon on the button (create doesn't either). Maybe I can propose it for 7. Possibly call it "browse receiver"? (A bit long though) Tim Sent from my iPhone
On 19 Jul 2017, at 19:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Tim, all
2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use.
It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand....
But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful.
Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction.
I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand:
I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier.
In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. Maybe now is time to retry ;)
Esteban
Regards!
Esteban A. Maringolo