An interesting question about the veracity of information seen in the debugger.
Given this snippet of code
// Get first key //
int? keyEDISecurity = this.WorkQueue.GetNextWorkItem();
// Done? //
while (keyEDISecurity != null)
// Write changes //
--> List<ISNLEditableObject> changedRows = this.WorkQueue.GetChangedRows((int)keyEDISecurity);
catch (Exception ex)
string errorMessage = "There was an exception processing KeyEDISecurity " + keyEDISecurity.ToString() +
" - " + ex.Message;
// output error info //
// Remove all data for the KeyEDISecurity from work queue cache //
// Get next work item //
keyEDISecurity = this.WorkQueue.GetNextWorkItem();
Before the line with the -->, the changedRows is null, as it should be. It then goes out of scope, as you get the next work item. You then come back in, and before the line with the --> if you access changedRows, it should be again null, as it hasn't be declared.
If you break and edit, then, as you expect, you can't access changedRows, because it's gone out of scope, and not been declared yet. If you evaluate it (either by mouseover or using the immediate window), you have access to the changedRows from the previous iteration of the loop. WTH?
Anyone seen this? It doesn't affect the program as it seems to act correctly in code, but the debugger issue caused a waste of time since it wasn't behaving as expected.