The output window in Visual Studio does not seem to be updating. When I manually switch the "Show output from" to any other option, then back to "Debug" it refreshes but otherwise, it does not refresh on its own. Does anyone know why this is occurring.
The commands System.Diagnostics.Debug.WriteLine() and SystemDiagnostics.Trace.WriteLine() both result in the same problem.
Are you familiar with Application.DoEvents();
Putting this immediately after your .WriteLines(); will allow the program to dispatch window events, otherwise you're simply going to see 'Not Responding' at the top of the screen. However, if you're displaying something in the interior of a detail loop, this will slow things down a lot. When it repaints the Trace screen, it's refreshing the entire window, not simply the line you just wrote.
Related
This seems to be a WPF-specific issue.
If I set a breakpoint in the code, the program will pause when it reaches that line, and I can edit/add/remove code, and then continue - it runs the newly edited code (ie, it behaves as expected).
However, if I hit 'Break All', I get moved to window that says "Your App has entered a Break State...". If I try to edit my code, nothing happens. I try to type but nothing happens - no text appears, and there's no errors that pop up or anything.
I don't have this problem in WinForms applications - just WPF. If I create a basic WPF project from the template, I still have the issue.
It's a very frustrating issue! My ugly hacked solution is to add a button to my program's UI called 'Break', which executes a single line of code that has a breakpoint on it, basically recreating the behaviour that 'Break All' should have.
Weirdly, it's not an issue if I'm on a WPF project which uses multiple threads. Hitting 'Break All' in this case acts as if there's a breakpoint on the line of code where the background thread is set up.
I am not sure..but you can give a try.
To enable/disable Edit and Continue. In the Options dialog box, expand the Debugging node, and select Edit and Continue. In the Options dialog box Edit and Continue page, select or clear the Enable Edit and Continue check box. The setting takes effect when you restart the debugging session
source:https://msdn.microsoft.com/en-us/library/ms164926.aspx
I'm using ReactiveUI in my WPF program, the WPF Window can be initialized and show normally, and I'm under Debug Mode,
but sometimes When I run some command code binding with button, it shows error below, and there're not more information, so I have no idea what's the reason to the Exception:
ReaciveUI.pdb contains the debug information required(...)
and after Continue, a window shows then the program was stopped:
An unhhandled Exception of type 'System.Exception' occured in ReactiveUI.dll
How to deal with this problem?
I found the keypoint of the problem later, the bug happens at
BtmCheckCmd = ReactiveCommand.CreateAsyncTask(
canBtmCheckCmd, //CanExecute
async _ =>//Execute
{
ProgressWinDow.RunCheckAndBarHandle();
MessageBox.Show("SomeThing");
}
I find a new way to check whrere the problem I former don't know so later I could found the solution.
In my case when the exception before happens, sometimes the messagebox show (sometimes not), then if the messagebox show, somtimes after click OK and the Exception Window Show, and if doing like this I can't find which part of my code does the problem haapen,
but if I click pause when the messagebox show(not click OK, but click pause under debug mode when msgbox show), then it go to the part of code it execute,
and by doing this I find the "Messagebox show" is in the code block of
async
in the part of code, and there're two method in async, so it should be the reason to this problem, maybe something wrong when async two method at the same time.
And In my case, the Messagebox is originally just used to test, so I delete the MessageBox and the problem solved.
Another way to find the problem in multi-thread is under debug mode,
and set the break points, then execute that part of code, when going into a break point, then go to the top ToolBar select :
Debug>>Windows>>Threads
then in the threads window can see what are the threads doing
In my case Visual Studio (2022) had locked a file.
To locate the locked file I did (in a console at the root of my project):
git clean -xfd
This gave me a message about several files which VS was locking.
But ultimately, the solution was to kill Visual Studio, perform a git clean, and then rebuild. You may also need to log out if on Windows to release the locked file(s) before rebuilding.
I'm just starting out with MonoMac in Xamarin Studio, and I've run into the strangest problem:
I a window with an NSButton and a NSTextField on it. By this point I've cut out the event handler on the button, so it doesn't DO anything, except highlight when I click it. The button creation code looks like this:
nsButton = new NSButton(new System.Drawing.RectangleF(0, 0, 100, 100));
nsButton.BezelStyle = NSBezelStyle.RoundRect;
nsButton.Font = NSFont.SystemFontOfSize(
NSFont.SystemFontSizeForControlSize(NSControlSize.Regular));
nsButton.StringValue = text;
...and then it gets added to the window like so:
nsView.AddSubview(control.Handle as NSView);
(because in this part of the code, control.Handle is typed as object, and nsView is the main view on the window).
All runs and works fine at first. But, if I click repeatedly on that button, eventually the window just closes. No error, no exception, and the app itself doesn't quit; menus continue to respond and cheerfully log messages when I use them. But the window is simply -- gone.
It's extremely repeatable: it happens after 21 clicks. If I add an event handler that updates the NSTextField (e.g. hello.Caption="Foo";), then it happens after 19 clicks. It doesn't matter whether I click fast or slow; it's always the same number of clicks. Note that there is no code in the project to close the window, and the window doesn't even have a close box; I know of no legitimate way to close it short of quitting the app.
I am baffled here, and don't know how to debug this further. Does Xamarin have some sort of evaluation limit that closes your windows after so-many events? Is it a framework bug? Any insight will be greatly appreciated.
But, if I click repeatedly on that button, eventually the window just
closes. No error, no exception, and the app itself doesn't quit; menus
continue to respond and cheerfully log messages when I use them. But
the window is simply -- gone.
This "disappearing without a trace" sometimes occurs when an application crashes in native code badly enough. This can occur due to bugs in the binding code or mistakes made in calling the native APIs that corrupt internal cocoa state. I believe you are using MonoMac, and that this particular issue has been fixed in Xamarin.Mac.
You can sometimes get more information from the output window or by attaching lldb to your process.
This turned out to be the same issue as this one, in a slightly different guise.
In short, I wasn't keeping a reference to the NSWindow object, but instead was letting it go out of scope. So the GUI window would stick around for a while, but eventually (after some number of events or other code creating behind-the-scenes garbage) it is noticed and disposed of by the garbage collector. The window is then torn down.
It's all perfectly reasonable once you think of it, and happens under both Xamarin and MonoMac (just at slightly different times).
The simple solution, of course, is to retain a reference to the window until you're truly done with it. Problem solved!
(And yes, I feel a bit sheepish, but hopefully this question will get found by future Mac C# developers, and save them some grief.)
I'm not sure how to explain this but occasionally I will experience an issue where I popup a dialog (say a file browser), and after it is closed, part of the dialog remains visible on top of my app. Sometimes if I minimize and restore it will go away.
Is this a common issue?
I have only ever seen this where the window that you are over stops responding and cannot update the area which has been revealed. However as soon as it does respond again then it redraws.
Maybe you could repeat this test and not minimize the window behind?
When I run my code within VS, when I enter certain methods, upon ending the application (closing the form) been debugged, VS does not end the debug session automatically forcing me to end it manually.
This doesn't always happen, the results are consistent with certain windows / classes loaded when the application is run within VS.
I want to know why this may be, I'm assuming its an indication of a file not been closed in my managed code or 'something' like that.
Why might this occur and how can I trace and fix it?
This would happen if your code keeps running after closing the window.
Pause the debugger after closing the window to find out what it's doing, then modify the code so that it stops running when you close the window.
On Debug menu, click "Detach All".
Hope that helps!
EDIT
Follow, SLak's advice, as that will go after the problem. My solution may only fix the symptom. I will leave the answer here just in case it is helpful to you though.
Good luck!