When I try to delete a breakpoint while debugging my ASP.NET app, it returns as soon as I stop the debugger. I don't know if this is a bug or an intended feature. If it is an intended feature, how do I turn it off?
If it is a bug, I can replicate it by:
1. Put a breakpoint in my code
2. Run the code in debug mode (F5)
3. When the code breaks at my breakpoint, press F9 to remove the break point. Then press F5 to continue.
4. Stop program execution (either by the stop button or closing the browser).
5. Breakpoint re-appears.
Note: if I go into the Breakpoints window and find the line with the breakpoint on it and delete it from there, it stays away. It just doesn't delete when I hit F9 while in break mode.
Related
I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.
Title quite much says it all.
In VB6, and in VBA/Access it was possible to hit break key, and jump into debug mode when using the msgbox() command.
Is there a way to do this in vb.net (desktop/winforms) applications?
Often, some code will toss up a dialog box, and it is rather nice then to jump into debug mode as a result of that message box having been displayed.
Edit
Ok, hitting pause button in most applications work, but in this application, when I hit pause, then I get this:
Edit two:
Ok, I have discovered the reason for this behavior. I have the application Frame work box un-checked. The reason for this is I did't want to specify the main application form as startup form, and I desired additional control over what occurs if the main startup form (that I don't specify) is closed. Thus, my main application form is launched via application.Run(my form)
It thus seems that due to starting the main form as a new separate application thread (which is the result of using application.Run(), then you can't use ctrl-break, or more common use/hit the pause button in the IDE to halt the code. Hitting pause will thus display that the application is running a main app thread, which indeed is the case since I use applicaiton.Run() to launch the main form from the classic and traditional Sub Main().
Edit 3
A way to fix this, and enable the pause key to work is to un-check in tools->debugging the [ ] Enable Just My Code. This will thus allow debug mode of the other "main" application thread.
Hmm. [CTRL][BREAK] clears the dialog box. However, clicking the pause button in the IDE will do what you want.
Alternatively, select Debug > Break All from the menu.
When I start a debug session, program execution halts at a line that appears to be breakpoint (yellow background color). I must press F5 to continue, and the program proceeds normally.
I call it a phantom breakpoint because no breakpoint appears to be set, and even though executions stops within a loop, I need only press F5 once to proceed.
I tried setting a breakpoint at the phantom location, and removing all breakpoints but to no avail.
The only other similar problems I can find are for Java, and MS-Access where the solution was to de-compile the application.
Although this is very annoying while in development, I was gritting my teeth and baring it until the application was installed on a Citrix server where an error message box is displayed saying that a breakpoint had been encountered.
As an afterthought, I just rebuilt the setup program and after running the application, a critical error was issued. In debug mode, the message was "myapp.exe has triggered a breakpoint:". I cannot explain why it works at all on the Citrix server).
I sure would appreciate any suggestions on how to resolve this issue.
TIA
You are running somebody else's code and that code has an explicit debugger break instruction compiled into the program. You can do so for example by writing Debugger.Break() in a managed program. It could also exist in unmanaged code, the __debugbreak() intrinsic or the DebugBreak() winapi function do this. Could be a simple oversight, it could be that it was intentionally left in the code to warn about a problem.
One way to find the programmer that did this is by using the debugger. Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option. Then Tools + Options, Debugging, General, untick the "Enable Just My Code" option.
Run the program and reproduce the condition. Now use Debug + Windows + Call Stack and look at the very top of the list. Scroll up if necessary. It might well be grayed out to indicate that this is not your code, it won't be. You'll see the name of a DLL there. Call the company or programmer that wrote that DLL and ask for advice.
I always write code like this:
If SomethingIsTrue Then
'DoThis
ElseIf SomeOtherThingIsTrue Then
'DoThat
Else
Debug.Assert (False)'Doh!! I forgot to handle a certain condition
End If
In VB6 this worked great. During testing my app in the IDE, it just stopped in the Debug.Assert(False) line, and I saw where I missed something.
But VB.NET does not stop there but instead gives me a huge messagebox. This seems to be standard behaviour for Debug.Assert.
I have 2 questions, please:
1) How can I make it stop smoothly in that line instead of showing the messagebox?
2) How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
Thank you!
I would write something along this line:
if debugger.isattached=True then
debugger.break
end if
Just wrap it in a shared sub, and you can simply call it in the else statement.
The code is typed without visual studio at hand, so I hope it will work.
How can I make it stop smoothly in that line instead of showing the messagebox?
Just click Retry on the message box that pops up. From MSDN:
Clicking Retry sends you to the code in the debugger if your application is running in a debugger, or offers to open a debugger if it is not.
Clicking Ignore will, well, ignore the message.
How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
I don't mean what you mean with at runtime, since all asserts happen while your code is running, hence at runtime.
If you mean that asserts should be ignored while running your application without a debugger, just make a release build instead of a debug build. The Debug.Assert method works only in debug builds, and the point of debug builds is that they are easy to debug.
If you want nonetheless suppress the message box, see Customizing Assert behavior:
For example, you could override the TraceListener.Fail method to write to an event log instead of displaying the Assertion Failed dialog box.
To customize the output in this way, your program must contain a listener, and you must inherit from TraceListener and override its TraceListener.Fail method.
I am following the Stanford University iOS development course on iTunes U.
In one of the demos (that I have been trying to follow), there is this code that loads the property list from an NSURL and returns it as NSMutableDictionary.
-(NSMutableDictionary *) words
{
NSURL *wordsURL=[NSURL URLWithString:#"http://cs193p.stanford.edu/vocabwords.txt"];
words=[[NSMutableDictionary dictionaryWithContentsOfURL:wordsURL] retain];
return words;
}
The application is successfully built, but at runtime it gives the following error and gets stuck:
I can't figure out what the problem is. Can you please help?
You're stopped at a breakpoint. That's a debugging tool, not an error. See the blue arrow/tab in the left margin, where the line numbers are? Drag that away and drop it anywhere (you'll see a "poof") to remove it, then run your project again.
You can also deactivate all breakpoints by typing ⌘-Y, the key equivalent for the menu item Debug>Deactivate Breakpoints, or you can view all your breakpoints in the Breakpoint Navigator (hit ⌘-6).
When execution stops like this, you can continue from the breakpoint, either by typing continue at the debugger prompt in the Console:
(lldb) continue
Or hitting the "Play" button in the debugger controls. You can also type Control-⌘-Y, which is the equivalent for the menu item Debug>Continue.
This isn't an error. You just set a breakpoint (probably without knowing it).
Drag the little blue Chevron in the column at the left out of the way. You will see it disappear and go poof, and then you can rebuild your app and you should see it run properly.
Now, that said, I think there are some memory management mistakes in your code, but we can return to those later. ;-)
The program is stopping because you have a breakpoint.. That's the blue arrow on the left of the code. Right-click it and delete.