[PATCH] Re: Bug 68015: Variables/Watch Window closes on first view

[Richard Dale]

On Monday 06 June 2005 10:46, Vladimir Prus wrote:
> On Monday 06 June 2005 04:03, jbb wrote:
> > I've tried this patch and it does not seem quite right to me.
> >
> > When stopping on a breakpoint the first frame is not selected and you
> > have to click the frame to get the variables to be displayed.
> >
> > I don't think we should force the user to click on a frame to get to see
> > the current state of the local variables when we stop.
> >
> > I suspect this isn't the intended behaviour?
>
> It isn't. Looking at the problem, it looks like now it works almost by
> accident:
>
> 1. When program stops, gdbcontroller.cpp issues the "info thread" command
> and then "backtrace"
> 2. The framestack controller tries to open the thread item corresponding to
>    selected thread, which in turn selects frame 0
> 3. The slotSelectFrame in gdbcontroller.cpp issues "info local" which
> populates the tree view.
>
> With my patch, at step 2 we don't issue selectFrame signal, so (3) does not
> work. I propose the following revised patch -- the only difference is that
> the actOnProgramPause now unconditionally issues "info locals".
Has anyone looked at the ruby debugger code and compared it with the gdb one? 
The code was derived from gdbcontroller, but I fixed quite a few issues like 
this as far as I can remember. Anyone familiar with gdbcontroller should find 
it easy to understand. It can display multiple frames on each step, which can 
be open or closed. It only fetches local variables for an open frame. And 
multiple frames persist between steps, until they go out of scope.

-- Richard