I am testing a user-defined override to BeforeSaveEntities on the Breeze Server Side. I have a breakpoint where I am observing the saveMap, and I call a method on the sub-class of the EFContextProvider to loop through each entity being saved.
Then when I click the Debug Stop button in Visual Studio, the Save still occurs. If I change the return from BeforeSaveEntities return from passing back the original saveMap to null, it does not.
This was a bit unsettling when I was going to "test" deleting...as I'm trying to write code that will do a "soft" delete.
Anyway, my question is, is there a workaround so I don't have to setup a "return null" during testing?
But more importantly, if I throw an EntityErrorsException it does stop the save as expected. :)
Thanks. Bob
This happens because you are just detaching the Visual Studio debugger from the running IIS/IIS Express instance. As soon as you detach the debugger, the request's execution continues on the webserver and thus, the rest of the code is executed.
A quick workaround would be to wrap your null return code in a compiler condition and check for the DEBUG symbol. Something along these lines:
#if DEBUG
return null;
#endif
Production code should be built using the RELEASE compiler symbol instead of the DEBUG symbol to enable deletion.
Related
When you break the debug in Visual Studio (through the Break All menu or the shortcut CTRL+ALT+BREAK by default), it jumps to the line of the call return.
(In my case, using winforms, it jumps to the Application.Run(); line of the Program.cs file).
It's kind of annoying when you're debugging a method and every time you hit Break All, the focus is set back on a file you weren't working on.
Is it possible to disable that jump? I couldn't find any option in the Debugging part of the VS options.
It's not "jumping" - it's breaking to the currently executing line of code. This is the behavior, and is not configurable.
If you want to have it stop at a specific line of code where you're working, you can just set a break point there, instead. This will cause it to break at your breakpoint as soon as it executes the code there.
I have a piece of code in C# that's essentially like the following...
WriteFile();
try {
RunTest();
} finally {
DeleteFile();
}
Now this has been planned so that even on failure, it cleans up the files it left behind. This works when not run in debug mode (although it pops up a message asking if I want to debug the program or close it. Closing it produces the appropriate results).
When I run this in debug mode and hit an exception inside of RunTest, I only seem to have two options. In the first one, I tell debugging to stop. This is equivalent to killing the program and the block in finally does not run (so the file doesn't get deleted like it should). If I tell it to continue, it doesn't propogate the exception up and instead, it just hits an exception somewhere else.
Is there anyway to get debug mode to continue like a normal program after hitting an exception?
From the Debug menu, choose Exceptions (or use Ctrl + Alt + E). This will bring up a dialog where you can uncheck appropriate checkboxes in the "User-unhandled" column for exceptions which you don't want to stop at while debugging.
I believe that will make exception propagation work normally. And you can still set a breakpoint either in the try or finally block to see what's happening.
Check Debug/Exceptions if there are any exceptions set.
Another option would be to handle the event Application.ThreadException (Windows Forms) or Application.UnhandledException (Silverlight etc.) and tell the application to continue or exit, depending on the severity of your exception.
Basically my problem is that I expect Visual Studio (2010 Professional) to be able to evaluate any Visual C++ expression in the watch window that it handles in the code I'm debugging, but apparently there's something preventing this from happening. For example, when dealing with CStrings, evaluating the method IsEmpty on the CString in the watch window gives me a Member function not found error, as does a basic equality comparison (in the code being debugged obviously no problems).
Am I missing something here, or is what I'm asking for too much? Obvious solution would be to put debugging statements in my code for whatever CString operation I'm looking for, but I would prefer not to have to do this.
Update/Example:
CString blah = _T("blah");
Calling blah.IsEmpty() in my code works fine, but in the watch window of the debugger I get the error above (CXX0052). The contents of the variable blah can be seen the watch window.
I could reproduce your problem, and, indeed, the VS watch window shows Member function not found alongside with the error code CXX0052.
In the MSDN documentation I found that this problem arises due to a call of a inlined function, the CString::IsEmpty() member function is probably somehow inlined (this is what the Watch Window evaluator sees), to solve the problem, first open your project Configuration and disable inlining
Second, still in the project Configuration, choose Use MFC in a Static Library (somehow the Watch Window keep seeing the called function as an inlined one if you use it as shared library, maybe this is because in the Shared Library the code is inlined and the Watch Window evaluator don't use the Debug builds of such runtime libraries).
Third, clean and Rebuild your Solution.
After that, the problem should be fixed (remember to refresh the expression if you see the value grayed out in the watch panel) during debugging. Remember to switch back to your original Debug options or better, create a new Debug profile to keep this settings.
I cannot open a new window in QT. I new in QT so I think I am missing something. I only write the code below and settings windows just shows itself and closes. I have commented out destructor but still problem persists.
SettingsWindow s;
s.show();
What do I do wrong ? By the way I cannot either debug it, debuger does not stop when it reaches to the first line for example.
Thanks
This can't possibly be the only code you wrote.
However, judging from your description the first thing that comes to mind is probably a missing call to QApplication::exec(). Somewhere in the code you haven't shown here there's an instance of QApplication, probably named app. After calling show on your window, make sure there's a call to exec.
Since you are using a non-pointer var, your window is destroy when it go our of scope (at the end of the function). If you use a pointer when exiting the function the memory is not deleted so you Windows will still be shown. But you will not be able to clean memory when closing the window if you can't anymore access to your pointer.
Maybe you need to create your window as member of the calling class in order to be able to destroy the window AND clean memory once you don't need anymore to display it (for example in the calling class destructor).
Normally in Visual Studio, a watch cannot be evaluated unless the debugger is stopped at a breakpoint. Is there a trick or add-on to make Visual Studio evaluate a watch while the application is still running? For example, evaluate the watch every time execution passes a point in the code while it's still running and without changing the code to insert statements like Debug.WriteLine.
Not sure this is possible, but I thought I'd ask.
Yes, this is possible. Set a breakpoint at the location where you'd want to see the value. Right-click the breakpoint and choose "When Hit...". Tick "Print a message" and write an expression like { value }. The message is displayed in the Output window while your program runs.
I would do that using compiler directives.
#if DEBUG
Debug.WriteLine
#end if
No this is not possible to do. The evaluation feature in Visual Studio is a stack frame based mechanism. That is that every evaluation is done in the context of a given stack frame (as viewed through the stack window). When the program is running the set of stack frames is currently changing and hence it's not possible to do a stable evaluation.
Additionally there are other limitations in the CLR which prevent this from managed code. It's not possible for instance to execute a function unless the debugee process is in a very specific state.