[PATCH] Re: Bug 68015: Variables/Watch Window closes on first view
ghost at cs.msu.su
Mon Jun 6 12:43:10 UTC 2005
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
1. When program stops, gdbcontroller.cpp issues the "info thread" command and
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".
Do not immediately switch frames and hide framestack widget, when
opening an item corresponding to a frame. Switch frame only when frame
item is explicitly selected.
(GDBController::slotProduceBacktrace): New slot. Gets backtrace for
a thread via "thread apply XXX backtrace" and so doesn't change current
(GDBController::actOnProgramPause): Unconditionally issue "info locals" so
that variables view is always updated when program stops.
(FramestackWidget::produceBacktrace): New signal.
(FramestackWidget::getBacktrace): New method.
(ThreadStackItem::setOpen): Only fetch backtrace when there are no
children. Otherwise, when viewedThread_->setOpen(true) is called
after parsing backtrace we immediately emit another signal.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4464 bytes
Desc: not available
More information about the KDevelop-devel