There are, of course, a number of undocumented limitations in the debugger. Chief among these is that it forces us to even think about the concept of displaying 255 fields. I had a chance to chat with the fellow over the debugger several years ago at LotusSphere. I asked him why in the world the LS debugger forces us to navigate through all those hierarchies instead of just providing a watch window. After explaining to him three times what a watch window is, he got very exited and said "Oh, that's a good idea!" Yes, and it was a good idea when Borland put it in the debugger for Turbo Pascal 3 in 1988! Do they actually USE Lotus Notes at Lotus?
None of that is going to help you of course. I am going to assume, however, that you are actually primarily interested in fewer than 255 fields in a given debugging session. I recommend that you create a "Watch" variable or two to help you in your debugging. A "Watch" variable is the name that I use for a variable that exists for no purpose other than so I can look at it while debugging.
Often, I create a string "Watch" variable that contains summary information from several other variables. This is especially handy when using a STOP statement to bring up the debugger when a piece of code first gets hit, so you know right away where you are in the process.
In your case, you are interested in fields on the document, so there is a "trick" you can exploit. Create a WatchItem as NotesItem variable, and then Set it to Doc.GetFirstItem("FieldNameOfYourChoice"). NotesItem variables store a reference to the actual element within the document's Items collection. So when the field (item) changes on the document, the NotesItem that has been set equal to it changes too and vice versa. In this way you can create several "Watches" and watch them change in the debugger as the document's fields are updated.
For more advice on debugging LotusScript, check out this article.
This was first published in September 2006