Debugging multi-window AppKit apps: Identifying the window associated with a breakpoint

Question

Created 1d

Replies 1

Boosts 0

Participants 2

When working on a multi-window AppKit app, how do you identify which window instance is associated with the current breakpoint?

The same question applies when using LLDB. If execution stops inside an object that can exist in more than one window, such as a shared NSViewController subclass, how do you know which window’s object you are currently inspecting?

Does Xcode provide a mechanism for showing the NSWindow associated with the current view, view controller or responder while debugging?

My current approach is to print object identities and compare them manually. For example, if several identical windows are open, I might print the current object and its window:

print(self, #function)

Then I interact with one window, make a note of the printed memory addresses in the console, switch to another window and compare the output. This works, but it feels manual.

I am not dealing with different window subclasses. The windows may be instances of the same class and may contain instances of the same view controller classes. I simply want an easier way to distinguish which window instance I am debugging.

Is there a recommended Xcode, LLDB or AppKit workflow for this?

Answer 1

Frameworks Engineer OP

Apple

1h

Breakpoints are not associated with windows. Breakpoints stop the process whenever a particular instruction is about to be executed. If that instruction belongs to a class that has many instances (e.g. windows), the breakpoint will be triggered no matter which window received events that led to that intsruction’s execution.

One way to orient yourself is to look at the Local Variables in Xcode when a breakpoint is hit. You can use the po debugger command to print out objects and their memory addresses. From there, you can deduce which instance you may be dealing with.

Another method is to use the UI debugger to find the instance of the window or view you want to debug. When you print that object’s description, its memory address is also printed. You can then use that address for comparison when your breakpoint is hit.

Hope that gets you further along.