Bug 1261 - [2.8] Values changes in immediate window don't reflect in Watch window
Summary: [2.8] Values changes in immediate window don't reflect in Watch window
Status: CONFIRMED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger (show other bugs)
Version: unspecified
Hardware: All All
: Lowest enhancement
Target Milestone: ---
Assignee: Bugzilla
URL:
: 7212 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-05 13:57 UTC by Mike Christensen
Modified: 2016-12-14 19:09 UTC (History)
5 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Sample code (338 bytes, text/plain)
2011-10-05 13:57 UTC, Mike Christensen
Details

Description Mike Christensen 2011-10-05 13:57:19 UTC
Created attachment 600 [details]
Sample code

Repro steps:

1) Run attached program, break on line 12 (after f is created)

2) Add "f" to the Watch list and expand it so you can see Width and Height.

3) Run the following in the Immediate window:

> f.Height
6
> f.Height = 7;
6
> f.Height
7

Results:

Height property in Watch window doesn't instantly change, and highlight in red.  Even if you delete it from the watch and add it back in, the value is still 6.

Expected:

Watch window should provide a real time view for the value of this property.
Comment 1 Jeffrey Stedfast 2011-11-18 17:04:15 UTC
From what I can tell, this would be a runtime bug. If I understand the MonoDevelop code correctly, it is sending the value over a socket to the runtime to set that value, and a later request for the value is not getting the new value.

(maybe the value change is queued to be set, but wasn't set yet? I don't know)
Comment 2 Jeffrey Stedfast 2011-11-18 17:08:54 UTC
Michael tells me this is a MonoDevelop feature request, apparently this is "by design". It would be too expensive to re-evaluate all expressions whenever a value is changed, because there's no way to track what side-effects it would have.
Comment 3 Jeffrey Stedfast 2012-09-18 12:35:27 UTC
*** Bug 7212 has been marked as a duplicate of this bug. ***
Comment 4 Jeffrey Stedfast 2013-06-06 14:52:35 UTC
The way to solve this, I think, would be to emit TargetStopped event on the DebuggerSession or something. This would cause the Call Stack window, the Watch pad and the Locals pad to all reload, though, which may be expensive.
Comment 5 Greg Munn 2016-12-14 19:09:30 UTC
Still an issue.

Note You need to log in before you can comment on or make changes to this bug.