I have a weird problem to explain here. I have a wizard with multiple screens. In my first screen I am reading an XML file and its been read and its values shown/used for screens. In one of the screen, I am changing these values and then hit Update button to update the data. But at the end of the wizard, when I click finish the changed values are not saved properly. I have confirmed this with code as well that the changed values were not present while exporting the data.
But the real kick came when I started debugging. Till now I was debugging only when the data is being exported. But then I started debugging from start of the wizard. I noticed while debugging that, when I hit Update button after changing values, this time the values were updated and correct data was exported. But when I run the application in runtime or put a debug point directly at export process, the changed data is not reflected.
So the problem is, when I debug the changed values are being exported and in runtime it do not. Can anyone suggest me something on this?
However I noticed later that sometimes in runtime its updating and sometimes not. But it gets always updated when I debug. If it matters, I am using Winforms and MVP.
EDIT
I must also admit that when I put Thread.Sleep(2000) at the end of Update button event method, everything looks good and works fine. But however this way is not being appreciated by my code reviewers and either this method is not pleasing me.
Edit Again
The Update button uses the main thread and updates the value in the same thread. However, when I click finish, its creating a BackgroundWorker and running a ExportData method from there. I cannot see any more threads there with my present observation and knowledge.
Related
Recently started a new project is VS2019 and "Edit and Continue" doesn't seem to be supported. By this I mean that I've enabled the various settings for it to work based on what I've found online and it simply doesn't seem to be possible.
Is this something incredibly daft that I'm doing or not doing, or does it just not work in VS2019 and I should go back to VS2017? Thanks.
Immediately after running in debug mode, edit any line of any file to get this:
Is this something incredibly daft that I'm doing or not doing, or does
it just not work in VS2019 and I should go back to VS2017?
The premise of Enable Edit and Continue in C# is that you should set a breakpoint in that function or just in the Page_Load function. And when you do some code changes or any others,you should move the cursor to the changes, and then VS will apply these changes while debugging.
Besides, when you do these changes and click Continue, these changes will be applied in the current debug process but you can not re-execute the breakpoint at the same time.
Solution
Set a breakpoint at the beginning of the method you want to debug. And when you write some changes later, please move the cursor into the changes so that the changes will be applied.
Then you can see the successful message about this.
Note that these changes are stored in a temporary repository for debugging purposes only and are not built into the output file at the same time. They are only built into the output file when you stop and restart debugging. And this is quite different from the C++ mode.
Hope it could help you.
While playing around with vars watching while debugging by means of Watch Table (below at both pictures) and Data Tips (at code field), I've faced with an odd thing as follows:
I can't get realtime variable watching. The first picture while debugging with breakpoint and second one with no any breakpoints. Both show i=1. In fact a value of <i> is much more than 1 and runs up, though. And I obtain always static values. I'm not sure if VS2015 provides such function as real time var watching.
Accidentally found that if press twice or more times the "Continue" button while Debugging, this refreshes values. But this no that I expected from VS2015 variable watching option.
I have recently changed from web site model to a web application model. One change that i noticed was that in a web site, while i was running the site on my browser locally, i could make changes to the .cs files and just refresh the browser for the changes to take effect.
However in a web application the .cs files seem to have a lock which does not allow me to edit the .cs file without stopping the debugging.
This gets kinda lengthy since i have to stop and run again instead of making changes on the fly.
Is there any debug setting to get around this?
Thanks in advance.
Here is my current Edit and Continue window with the current settings. Do i need to change anything here?:
You can modify the code in a Web Application while the code is paused. You'll need to set a break point above the line of code you wish to change. Execute the code to reach the break point, and then while you are stopped at the break point you can modify the code. The once the modification is done you can resume execution.
There are certain things you cannot change while paused like this, like adding in a new method. If the change cannot be accepted while paused Visual Studio will tell, however, it won't tell you what exactly is doesn't like.
The feature you are looking for is "Edit and Continue" and should be in Debug>Options and Settings>Debugging>Edit and Continue. This doesn't give you the complete flexibility to change anything you want but does allow some basic changes.
In vb6 you could see a textbox update immediately when the value was changed, but I've noticed in .net that it will not update until after the method you are in has been exited. A preliminary question I have is whether there is a way to make the textbox update before the method is completed.
The issue is that I have two textboxes whose Text properties are set and when the method completes, only one of them consistently updates on screen. The other usually does not, but sometimes does. It's very sporadic. I literally called someone over to verify I wasn't taking crazy pills and of course it started working when she came over (though I made no code changes). Then when the QA guy came around it stopped working again (again, didn't make any code changes).
All I've been doing is setting break points and stepping through code trying to figure out what's keeping this text box from being updated. At the end of the procedure, right before it exits, I can check on the Text property and it has the correct value, but as soon as the method finishes it disappears.
I will try to get a code snippet up soon, but in the meantime I would love to know if anyone else has had this problem and any good ideas on how to debug b/c I'm getting a bit frustrated! There is a timer on the form that is enabled at a certain point and disables itself when it's run... setting a breakpoint in this timer verifies that it is not the culprit b/c the breakpoint never gets hit. But I am wondering if there could be some other asynchronous process I might be missing... I don't think so but if you can tell me anything I should be looking for that I might not have thought of please do.
Edit: I would post a code snippet, but the snippet I wanted to post doesn't reproduce the problem and I have not isolated the problem to a small enough section of code for it to be practical to post. I will add a little more info though:
After the method that updates these textboxes is completed, control returns to the form. There are no other processes going on. I kept thinking maybe some code was getting run somewhere that was blanking out the textbox but a thorough look through the code has confirmed this is definitely not the case... when the method completes nothing else happens.
I noticed when I was debugging that sometimes it would work properly, and on a rare occasion it would even work properly when running normally. I added a DoEvents() to see if it would work and it did the first time... but then did not continue to work. Out of frustration I added repeated calls to set the textbox and DoEvents() after each one and that did not make it perfect. Lastly I added a call for the thread to Sleep() for 300 milliseconds and it seems to be better now.
Keep in mind that there is another almost identical textbox on the form that gets set in the same procedure and never has any problem updating whatsoever. I have searched for any difference between the two controls and aside from size, location, and name I cannot find any difference.
I suppose you could add: Application.DoEvents() after you set the textbox text value. Its usually frowned upon to use DoEvents, though it may solve your issue in the intermediate.
i think you better use Invalidate(); this will cause control to redraw yourtextbox.Invalidate();
you can use Threading for this purpose
Recently, I've run into a classical Heisenbug. Here's the situation:
I have a tree list, the master view, in one panel, and a detail view in another panel to the right, that displays information about the currently selected tree node. (Very similar to Windows Explorer.)
When I add a new node to tree (think of right-clicking a folder in Windows Explorer and saying "New -> Folder"), the newly created node gets selected.
And here's the bug: The detail view on the right should get updated to show the new node. However, it doesn't. I have to switch to another tree node once, before I can see information about the new node in the detail view.
The bug is easily reproducible and happens in both "Release" and "Debug" build configurations. But: As soon as I set a breakpoint in the event handler (for the "Add new node" menu entry) and enable it, everything works fine =>Heisenbug! I don't have to do any real debugging. Clicking "continue" after the breakpoint gets hit is enough.
For better understanding, I've made a video that should illustrate what's going on.
Everything I could think of to get rid of the issue was putting the thread (the application is single-threaded) to sleep for a few seconds, but that doesn't work.
I'd greatly appreciate any suggestions on what I could try to determine the cause of the issue. Or maybe someone has a guess about the cause?
I'm targeting the 3.5 framework and using x86 as solution platform. The tree list control is from DevExpress' WinForms controls; Visual Studio version is 2010.
Thanks
Update 3: Issue solved. The problem was that the call to the detail view's Focus() method didn't trigger the GotFocus event, which is crucial for updating the detail view. (I don't know why, probably it already had the focus.) However, the method did not fail, it simply did nothing.
Now I just focus another control before focussing the detail view and that's it. The reason why everything worked fine during debugging was that switching from Visual Studio back to my application correctly set the focus on the detail view.
A major obstacle in hunting down this issue was that setting a breakpoint in the GotFocus event handler is useless: anytime you try to switch back from Visual Studio to the app, the GotFocus event gets re-triggered, and you're stuck in an endless loop. Comments on how that could be worked around are welcome.
Anyway, my specific problem is solved.
Thank you very much to everybody who answered or commented. It helped me a lot.
Update 2: In my code, I select the newly created node in the tree. This triggers a FocusedNodeChangedEvent. In the corresponding event handler, I update the detail view and call its Focus() method.
It seems as if that fails when there's no breakpoint set. I think what triggers the correct update during debugging is that the detail view automatically gets the focus.
Window messages
Update 1: Here are the window messages that Eddy's answer provided. (Long list of messages deleted)
First time I've seen a video to support an SO :)
I'm thinking that the right-hand pane, or control group, need(s) to have Invalidate() called - which I think the breakpoint is triggering because it switches to VS, overdrawing the window. Then, when you switch back again, it forces everything to redraw, thus making it work.
When you have a "heisenbug" you need to see what is going on but with a lighter touch that doesn't interrupt the flow of the program.
I would suggest that you form an hypothesis about where your problem lies. I would then edit the code to include calls to the various methods of the Debug class, that test the hypothesis or just give runtime information for diagnosis. Then run your code in debug mode and see what you get in the output.
If you have a more elusive "hiesenbug" theat occurs only in release mode you would need to roll you own logging mechanism to gather your evidence.
Put a System.Diagnostics.Debugger.Break() in the update routine for the other window. Then when the bug appears, a run time break point will be fired and you can view the stack.
It seems that the problem has to do with not getting the right event called to trigger and update to the child panel. When hitting the breakpoint your app loses focus and when you return it gains it again (which is a difference from running it). In order to inspect what events are and aren't called and what the difference is between the two scenario's add the following code to your form to see all the window messages that appear.
protected override void WndProc(ref Message winmsg)
{
base.WndProc(ref winmsg);
System.Diagnostics.Debug.WriteLine(winmsg.Msg + " - " + winmsg);
}
Comparing the differences might help you in determining a way how to workaround this problem.