Chapter 8. Debugging XML Web Services with Visual Studio .NET

In this chapter, you will learn how to:

  • Debug XML Web services using the Microsoft Visual Studio .NET debugger.

  • Use and configure breakpoints.

  • Break the debugger’s execution when exceptions are thrown.

  • Step through code statements using the debugger.

Even the most experienced and careful programmer will make mistakes when writing code. These mistakes fall into two categories, compile-time errors and run-time errors. Compile-time errors are those that prevent you from compiling your project, perhaps because you made a typing error or entered a code statement that is illegal. Visual Studio .NET helps you fix compile-time errors by highlighting problems in the code editor and reporting errors from the compiler.

Run-time errors are more complex. Your project compiles successfully but does not behave as you expect; you have entered code statements that the compiler understands but introduced an error in the application logic. Tracking down run-time errors can be a difficult process, so the designers of Visual Studio .NET included a powerful debugging tool to assist programmers in this task.

The Visual Studio .NET debugger is one of the most advanced and comprehensive tools that we have seen for any development environment; it is truly a best of breed product. The overall ease of use and flexibility simplifies the usually complex process of tracking down run-time errors. This chapter explains how to debug XML Web service projects by using features of the Visual Studio .NET debugger.

Note

The Visual Studio .NET debugger can be used with all types of .NET applications, including XML Web services, console applications, Windows Forms applications, and Web Forms applications. Although this chapter focuses on debugging XML Web services, the techniques that we describe here can be applied to the testing of other kinds of projects, including those that consume XML Web services.

Breakpoints and Exceptions

The basic purpose of a debugger is to run your application normally until the project encounters a break, at which point the execution of your code is paused and you can use the features of the debugger to explore the state of your application. When you are finished exploring, the debugger continues running your code as usual until the next break is reached.

There are two ways to cause a break. The most common approach is to add a breakpoint to your code file. A breakpoint is an instruction to the debugger that says, "Suspend the execution of my project when you reach this line of code." The second approach is to request that the debugger suspend execution when an exception is thrown, either by the code you have entered into your project or by one of the Microsoft .NET library classes.

Using Breakpoints

In the following sections, we will create an XML Web service that we’ll use to demonstrate the features of the Visual Studio .NET debugger. Once we have created and prepared the project for debugging, we will explain how to cause a break using a configurable breakpoint.

Creating the XML Web Service Debugging Project

The XML Web service we’ll use to demonstrate the debugger is based on the XML Web service example we built in the section "Using Custom Fault Codes" in Chapter 7.

Before we can debug our XML Web service, we need to make some changes to the project. By default, Visual Studio .NET expects a programmer to use Microsoft Internet Explorer to invoke XML Web service methods. However, because our project uses complex types as arguments, we cannot use Internet Explorer to invoke the ValidateCard method. Instead, we will use a Windows Forms client that will invoke the ValidateCard method using the SOAP protocol.

Procedure 8-1. Create the Project

  1. Open the project that you created in Chapter 7. The URL for this project should be http://localhost/XMLWebServices/Chapter07/CustomFaultCodes/ValidatorService.

  2. Select Copy Project from the Project menu, and then copy the project to http://localhost/XMLWebServices/Chapter08/Debugging/ValidatorService.

  3. Open the new project in Visual Studio .NET, and then save the solution file for the new project.

Procedure 8-2. Prepare the Project for Debugging

  1. In Solution Explorer, right-click the Validation.asmx file and select Set As Start Page from the shortcut menu.

    Prepare the Project for Debugging

    Setting the start page tells Visual Studio .NET which XML Web service file should be loaded when the debugger is started. We have only one .asmx file in our example project, but should you develop a project that contains multiple XML Web service files, this feature allows you to select a specific file.

  2. Select the ValidatorService item in Solution Explorer, and then choose Properties from the Project menu.

  3. Click on the Configuration Properties folder icon.

  4. Click on the Debugging item in the list.

    This loads the properties that relate to the Visual Studio .NET debugger.

    Prepare the Project for Debugging
  5. Change the Debug Mode setting to Wait For An External Process To Connect.

    The Wait For An External Process To Connect setting allows you to use a Windows Forms client for debugging. When the debugger is started, Visual Studio .NET will wait until an XML Web service request is received. This differs from the default mode, in which Internet Explorer is started as soon as the debugger is started.

  6. Click OK to close the properties dialog box.

  7. Build the project by pressing Ctrl+Shift+B or choosing Build Solution from the Project menu .

Creating the XML Web Service Client

To debug our XML Web service project, we will create a new client that is based on the client template project that we introduced in Chapter 7.

Procedure 8-3. Create the Client Project

  1. Copy the client template project to the location C:XMLWebServices­SBSProjectsChapter08. (For details about copying the template, see the sidebar "XML Web Service Client Projects" in Chapter 7

  2. Open the copy of the client template project in Visual Studio .NET.

  3. Add a Web reference pointing to the XML Web service that we created in the previous section of this chapter. The URL for that example is http://localhost/XMLWebServices/Chapter08/Debugging/ValidatorService/Validation.asmx. (Refer to the steps in the section "Creating a Web Reference" in Chapter 4 if you need more details on how to add a Web reference.)

  4. In Solution Explorer, right-click the Web reference and then select Rename from the shortcut menu. Change the name of the reference to Validator.

  5. Open the Form1 code file by double-clicking the Form1 entry in Solution Explorer (either Form1.cs or Form1.vb, depending on which language you are using).

  6. Double-click on the Validate button in the Form1 design view. This opens the source file for the Form1 class.

  7. Add the following code statements so that the ValidateButton_Click method is complete. This code is executed when the user clicks the button. The changes from the template code are marked in bold. We have added these statements to make exploring the debugger easier. By default, the XML Web service proxy class will wait for 30 seconds for a response from the server before assuming that a problem exists and throwing an exception. The statements that we have added to the example cause the client to wait indefinitely.

    Example 8-1. C#

    private void ValidateButton_Click(object sender, 
        System.EventArgs e) {
        // create the ValidationObject that we will send to 
        // the XML Web service
        ValidationObject x_object = new ValidationObject();
    
        // set the card type for the validation object based
        // on the user selection in the CardType ComboBox
        switch (CardType.Text) {
            case "AMEX":
                x_object.o_card_type = CARD_TYPE.AMEX;
                break;
            case "MasterCard":
                x_object.o_card_type = CARD_TYPE.MASTERCARD;
                break;                                
            case "VISA":
                x_object.o_card_type = CARD_TYPE.VISA;
                break;
        }
    
        // set the card number value in the ValidationObject
        x_object.o_card_number = CardNumber.Text;
    
        try {
            // request validation from the XML Web service
            // via the proxy class
            ValidatorService x_service = new ValidatorService();
            // set the time out to "infinite" to prevent the 
            // client from timing out while we use the debugger
            x_service.Timeout = System.Threading.Timeout.Infinite;
            x_service.ValidateCard(ref x_object);
    
            // set the text of the result label based
            // on the response from the XML Web service
            if (x_object.o_valid) {
                Result.Text = "Number Valid";
            } else {
                Result.Text = "Number Invalid";
            }
        } catch (System.Web.Services.Protocols.SoapException x_ex) {
            switch (x_ex.Code.ToString()) {
                case "Client.IllegalCharacter":
                    Result.Text = "Illegal Character";
                    break;
                case "Client.InvalidLength":
                    Result.Text = "Invalid Length";
                    break;
                case "Client.InvalidPrefix":
                    Result.Text = "Invalid Prefix";
                    break;
                default:
                    Result.Text = "Unexpected Error";
                    break;
            }
        }
    }

    Example 8-2. Visual Basic .NET

    Private  Sub ValidateButton_Click(ByVal sender As Object, ByVal e _
        As System.EventArgs) Handles ValidateButton.Click
        ’ create the ValidationObject that we will send to 
        ’ the XML Web service
        Dim x_object As ValidationObject =  New ValidationObject() 
     
        ’ set the card type for the validation object based
        ’ on the user selection in the CardType ComboBox
        Select Case CardType.Text
            Case "AMEX"
                x_Object.o_card_type = CARD_TYPE.AMEX
            Case "MasterCard"
                x_Object.o_card_type = CARD_TYPE.MASTERCARD
            Case "VISA"
                x_Object.o_card_type = CARD_TYPE.VISA
        End Select
     
        ’ set the card number value in the ValidationObject
        x_Object.o_card_number = CardNumber.Text
     
        Try
            ’ request validation from the XML Web service
            ’ via the proxy class
            Dim x_service As ValidatorService =  New ValidatorService()
            ’ set the time out to "infinite" to prevent the 
            ’ client from timing out while we use the debugger
            x_service.Timeout = System.Threading.Timeout.Infinite
            x_service.ValidateCard(x_object)
     
            ’ set the text of the result label based
            ’ on the response from the XML Web service
            If x_Object.o_valid Then
                Result.Text = "Number Valid"
            Else 
                Result.Text = "Number Invalid"
            End If
         Catch x_ex As System.Web.Services.Protocols.SoapException
            Select Case x_ex.Code.ToString()
                Case "Client.IllegalCharacter"
                    Result.Text = "Illegal Character"
                Case "Client.InvalidLength"
                    Result.Text = "Invalid Length"
                Case "Client.InvalidPrefix"
                    Result.Text = "Invalid Prefix"
                Case Else
                    Result.Text = "Unexpected Error"
            End Select
        End Try
    End Sub
  8. Build the solution by pressing Ctrl+Shift+B or selecting Build Solution from the Project menu.

Setting a Breakpoint

Now that we have built the XML Web service and the client that consumes it, we can set a breakpoint that will cause the debugger to suspend execution of the code.

Procedure 8-4. View the XML Web Service Code File

  1. Open the XML Web service project that you created at the start of this section.

    It might seem strange to close the XML Web service project and then create the client and open the service again, but we can’t debug the project unless we have a client to use, and we could not create the client without adding a Web reference to the service.

  2. In Solution Explorer, right-click on the Validation.asmx file and select View Code from the shortcut menu.

Procedure 8-5. Set the Breakpoint

  1. Scroll down the code file until you reach the ValidateCard method.

  2. Find the statement that creates the Validator object. The statement is as follows:

    Example 8-3. C#

    Validator x_validator = new Validator();

    Example 8-4. Visual Basic .NET

    Dim x_validator As Validator = New Validator()
  3. Right-click the statement, and select Insert Breakpoint from the shortcut menu.

    Visual Basic .NET

    Visual Studio .NET will insert a breakpoint, indicated by a red circle in the left margin of the code file, for the ValidateCard method. Here’s how the C# code file looks after adding the breakpoint:

    Visual Basic .NET

Stepping with the Debugger

With a breakpoint set, we can start the Visual Studio .NET debugger and use the client to trigger the breakpoint. When the debugger suspends the execution of the code, we use the basic features of the debugger to step through the code. We will also show you in this section how Visual Studio .NET allows you to control the execution of the code once a breakpoint has been triggered.

Procedure 8-6. Start the Debugger and Trigger the Breakpoint

  1. Select Start from the Debug menu (or press F5).

    This command starts the Visual Studio .NET debugger. You will see the windows within Visual Studio .NET change and the code window expand to fill more of the screen. We explain the purpose of these windows in the sidebar "Advanced Debugging Features" later in the chapter.

  2. Start the client application.

    Using Windows Explorer, execute the client application we created earlier in this chapter. C# programmers can find the file at C:XMLWebServicesSBSProjectsChapter08 WindowsFormsClientindebugWindowsFormsClient.exe. Visual Basic .NET programmers will find the file at C:XMLWebServicesSBSPro­jectsChapter08 WindowsFormsClientinWindowsForms­Client.exe.

  3. Ensure that the VISA item is selected as the card type, and then enter 1234 as the card number. The following screen shot shows the client interface with these details.

    Start the Debugger and Trigger the Breakpoint
  4. Click the Validate button.

    Clicking the Validate button will cause the client to invoke the ValidateCard method of the XML Web service. Because we have placed a breakpoint at the start of this method, the Visual Studio .NET debugger will suspend the execution of the service project at this point. The following screen shot shows the code window once the breakpoint has been triggered.

    Start the Debugger and Trigger the Breakpoint

Procedure 8-7. Step Through the Code

  1. Select Step Over from the Debug menu, or press the F10 key.

    Step Over instructs the debugger to execute the next line of code in the ValidateCard method. Notice that the line where we placed the breakpoint is highlighted in red and that the next code statement (the debugger ignores comments) is highlighted in yellow. The yellow highlighting indicates the code line that is about to be executed. Here’s the window for the C# code file:

    Step Through the Code
  2. Press F10 again to execute the switch (C#) or Select Case (Visual Basic .NET) statement. The yellow highlighting jumps to the code section that processes VISA requests. Stepping through the code follows the execution of the XML Web service, allowing you to see which statements will be executed for a request from a client. In this case, because we specified that we wanted to validate a VISA card number, the debugger has jumped to the VISA clause of the switch/Select Case statement.

  3. Press F10 until the throw GetException statement is highlighted.

    We asked you to supply a card number that we knew was invalid to ensure that this statement would be executed. Remember that the CreditCardValidation.dll library throws exceptions to indicate different types of problems with card numbers.

    Example 8-5. C#

    throw GetException(x_ex);

    Example 8-6. Visual Basic .NET

    Throw GetException(x_ex)
  4. Select Step Into from the Debug menu, or press the F11 key.

    Step Into differs from Step Over in only one respect: if the statement that is executed is a function call, Step Over executes the entire function and then highlights the next code statement in the current method. Step Into moves the highlight to the first statement within the called function. Selecting Step Into for a statement that is not a function call is the same as selecting Step Over.

    In our case, we have stepped into the GetException function, and the highlight is moved to the start of the If statement.

  5. Select Step Out from the Debug menu, or press Shift+F11.

    Step Out is used when you are stepping through the code inside a function and want to return to the calling function. In our case, we have stepped out of the GetException method back to the ValidateCard method.

  6. Select Continue from the Debug menu, or press F5.

    Continue instructs the debugger to resume execution of the code until the next breakpoint is reached. Because we have created only one breakpoint, the ValidateCard method will be completed and the result will be returned to the client.

  7. Select Stop Debugging from the Debug menu, or press Shift+F5 to stop the debugger.

    Visual Studio .NET will close the debugger and restore your code editing windows.

Configuring Breakpoints

The breakpoint we created in the previous section causes the debugger to suspend execution every time that it’s encountered. Although this is the most common way of using breakpoints, Visual Studio .NET provides additional support to create conditional breakpoints. Conditional breakpoints are triggered only when a condition specified by the programmer is met. In this section, we explain how to create different types of conditional breakpoints.

Using the Hit Count

Visual Studio .NET allows a programmer to create breakpoints that are triggered after they are hit a certain number of times; a breakpoint is hit when the statement that the breakpoint is assigned to is executed.

Procedure 8-8. Configure the Breakpoint

  1. Right-click on the code statement that is marked in red in the code window, and then select Breakpoint Properties from the shortcut menu. The Breakpoint Properties dialog box appears.

    The Breakpoint Properties dialog box shows the conditional settings for the selected breakpoint.

    Configure the Breakpoint
  2. Click the Hit Count button to display the Breakpoint Hit Count dialog box.

    The value of the When The Breakpoint Is Hit combo box is set to Break Always, which is the default behavior for new breakpoints. Each time the breakpoint is hit, the debugger suspends execution.

  3. Select Break When The Hit Count Is Greater Than Or Equal To from the combo box list. Set the numeric value in the field to the right of the combo box to 2. You can see the correct settings here:

    Configure the Breakpoint

    This combination of settings specifies that after the breakpoint has been hit a certain number of times it will be triggered on each subsequent hit. In our example, the breakpoint will not be triggered the first time that it is hit but will be triggered for each hit thereafter.

  4. Click OK to close the Breakpoint Hit Count dialog box.

  5. Click OK to close the Breakpoint Properties dialog box.

Trigger the Breakpoint

  1. Select Start from the Debug menu (or press F5).

  2. Start the client application, following the directions provided in the previous section, "Stepping with the Debugger."

  3. Select a card type and enter a card number using the client interface; the type of card and the number you enter are not important to this example.

  4. Click the Validate button.

    Clicking the Validate button causes the client to invoke the ValidateCard method in the XML Web service project. Although we have created a breakpoint in this method, the debugger does not suspend the execution of the code because we specified a threshold of two hits and the breakpoint has only been hit once so far. The client interface should display the result of the validation request as though the debugger were not running.

  5. Click the Validate button again.

    Because this is the second time that the ValidateCard method has been invoked by the client, the hit count condition for the breakpoint has been met and the debugger suspends the execution of the code. Once a breakpoint has been triggered, you can use all of the features of the debugger in the same way as for a breakpoint that is triggered for every hit.

Reset the Hit Count

  1. In Visual Studio .NET, right-click on the code statement on which we set the breakpoint and select Breakpoint Properties from the shortcut menu.

    This command opens the Breakpoint Properties dialog box.

  2. Click the Hit Count button to open the Breakpoint Hit Count dialog box. This dialog box shows the current value of the hit count.

    Reset the Hit Count
  3. Click the Reset Hit Count button.

    We have now reset the hit count, meaning that the debugger will not suspend execution the next time that the breakpoint is hit. Notice that we are able to change the properties of the breakpoint without stopping the debugger.

  4. Click OK to close the Breakpoint Hit Count dialog box.

  5. Click OK to close the Breakpoint Properties dialog box.

  6. Select Continue from the Debug menu or press F5 to resume code execution so that the result of the validation request is returned to the client.

  7. Select Stop Debugging from the Debug menu, or press Shift+F5 to stop the debugger.

Breaking on Conditions

In addition to triggering a breakpoint based on a hit count, the Visual Studio .NET debugger allows programmers to specify an expression that is evaluated to determine whether the breakpoint should be triggered. For example, a breakpoint could be triggered when a variable is set to a specific value or the return value from a method is outside of the expected set of results.

We can also use conditional breakpoints to monitor the result of an expression and have the breakpoint triggered when the result of the expression changes. Each time that the breakpoint is hit, the debugger evaluates the expression and suspends execution if the result has changed since the last hit.

Procedure 8-9. Configure the Breakpoint

  1. In the Visual Studio .NET code window, right-click on the code statement that is highlighted in red and select Breakpoint Properties from the shortcut menu. The Breakpoint Properties dialog box appears.

  2. Click the Condition button to open the Breakpoint Condition dialog box.

  3. Enter the following statement into the text box.

    Example 8-7. C#

    p_object.o_card_number == "999"

    Example 8-8. Visual Basic .NET

    p_object.o_card_number = "999"

    The expression we have specified causes the breakpoint to trigger when the client asks the XML Web service to validate a card with the number 999.

    Visual Basic .NET
  4. Select the Is True option.

  5. Click the OK button to close the Breakpoint Condition dialog box.

  6. Click the OK button to close the Breakpoint Properties dialog box.

Trigger the Breakpoint

  1. Select Start from the Debug menu.

  2. Start the client application.

  3. Select any card type and enter 999 as the card number using the client interface.

  4. Click the Validate button.

    Clicking the Validate button will cause the client to invoke the ValidateCard method in the XML Web service. However, even though we have specified 999 as the card number for the breakpoint condition, the debugger does not suspend the execution of the code. This is because the hit count condition that we defined in the previous section still applies to the breakpoint; the Visual Studio .NET debugger allows you to combine hit counts and conditions together to create sophisticated rules for controlling how breakpoints are triggered.

    Because we have not removed the hit count condition, our breakpoint will be triggered only when the client makes a second request with a card number of 999.

  5. Click the Validate button again.

    The debugger now suspends the execution of the code.

  6. Select Continue from the Debug menu, or press F5 to resume execution of the code.

Change the Breakpoint Condition

  1. In the Visual Studio .NET code window, right-click on the code statement that is highlighted in red and select Breakpoint Properties from the shortcut menu. The Breakpoint Properties dialog box appears.

  2. Click the Condition button to open the Breakpoint Condition dialog box.

  3. Enter the following statement into the text box.

    p_object.o_card_number

    The expression we’ve specified causes the breakpoint to trigger when the card number changes.

    Change the Breakpoint Condition
  4. Select the Has Changed option.

  5. Click the OK button to close the Breakpoint Condition dialog box.

  6. Click the OK button to close the Breakpoint Properties dialog box.

Trigger the Breakpoint

  1. Click the Validate button in the client.

    The debugger will not suspend execution because the card number that the client has sent to the XML Web service has not changed since the last time that the breakpoint was hit.

  2. Enter 1000 into the Card Number text box in the client.

  3. Click the Validate button.

    The debugger suspends execution of the code because the result of the expression that we entered for the breakpoint has changed.

  4. Select Continue from the Debug menu, or press F5 to resume execution of the code.

  5. Select Stop Debugging from the Debug menu to close the debugger and return to the normal Visual Studio .NET view.

Disabling and Removing Breakpoints

The Visual Studio .NET debugger allows the programmer to disable as well as remove breakpoints when they are not needed. Even when the trigger conditions are met, a disabled break will not be triggered. Disabled breakpoints can be enabled when they are required again. Deleting a breakpoint removes it from the code file. Deleted breakpoints cannot be restored, they must be re-created.

Procedure 8-10. Disable and Enable the Breakpoint

  1. In the Visual Studio .NET code window, right-click the breakpoint and select Disable Breakpoint from the shortcut menu.

    The red circle in the margin of the code file becomes hollow. The following screen shot shows a disabled breakpoint. While disabled, the breakpoint will not be triggered.

    Disable and Enable the Breakpoint
  2. Right-click the disabled breakpoint, and select Enable Breakpoint from the shortcut menu.

    The breakpoint is enabled and the hollow red circle changes back to a solid circle to indicate that the breakpoint is active.

  3. Right-click the breakpoint, and select Remove Breakpoint from the shortcut menu.

    The breakpoint is removed from the code file. Deleting a breakpoint is a permanent action; you must create a new breakpoint if you need to suspend execution at this statement.

    Tip

    All of the breakpoints in a project can be disabled or removed at once by using the Disable All Breakpoints and Clear All Breakpoints commands on the Debug menu.

Breaking on Exceptions

The Visual Studio .NET debugger can be configured to suspend execution in response to exceptions being thrown. In this section, we will set an exception policy that will cause the debugger to suspend the execution of the project code when an instance of the CCIllegalCharacterException is thrown. This exception is thrown by the CreditCardValidation library when a card number contains an illegal character. Once we have created a policy for the exception, we will start the debugger and use the client to send a validation request that we know will cause CCIllegalCharacterException to be thrown.

Procedure 8-11. Set the Exception Policy

  1. Select Exceptions from the Debug menu, or press Ctrl+A+E to open the Exceptions dialog box.

    Set the Exception Policy

    The Exceptions dialog box displays a tree of the exceptions contained in the .NET Framework class library; expanding the tree shows the exceptions grouped by namespace. We want to define an action for an exception contained in our example library, so we must add the exception to the list.

  2. Select Common Language Runtime Exceptions from the list of exceptions in the Exceptions dialog box.

  3. Click the Add button to open the New Common Language Runtime Exceptions dialog box.

    Set the Exception Policy
  4. Type XMLWebServicesStepByStep.CreditCardValidator.CCIllegalCharacterException into the Name text box.

  5. Click the OK button to close the New Common Language Runtime Exceptions dialog box.

  6. Click on the + symbol next to the Common Language Runtime Exceptions tree node to expand the tree of exceptions.

  7. Scroll to the bottom of the list, and then click on the exception name we just created.

  8. In the When The Exception Is Thrown section of the dialog box, select the Break Into The Debugger option.

    We have told the debugger to break when the CCIllegalCharacterException is thrown. You can see the configured exception entry in the following.

    Set the Exception Policy
  9. Click the OK button to close the Exceptions dialog box.

Procedure 8-12. Break on the Exception

  1. Select Start from the Debug menu to start the Visual Studio .NET debugger.

  2. Using the client application, select VISA as the card type and enter baddata as the card number.

  3. Click the Validate button.

    Clicking the Validate button causes the client to send the validation request to the XML Web service. We have specified a card number that we know will result in the CCIllegalCharacterException exception being thrown.

    The Visual Studio .NET debugger shows a dialog box indicating that the exception we are interested in has been thrown. The dialog box shows the details of the exception.

    Break on the Exception
  4. Click the Break button in the dialog box.

    Clicking the Break button suspends the execution of the project code in the same way that triggering a breakpoint does. Clicking the Continue button would have continued the execution of the code from the point at which the exception was thrown.

  5. Select Continue from the Debug menu to resume execution of the code.

  6. Select Stop Debugging from the Debug menu to close the debugger.

Chapter 8 Quick Reference

To

Do This

Start the Visual Studio .NET Debugger

Choose Start from the Debug menu, or press F5.

Stop the Visual Studio .NET Debugger

Choose Stop Debugging from the Debug menu, or press Shift+F5.

Set a breakpoint

Right-click on a statement in the code window, and then select Insert Breakpoint from the shortcut menu.

Disable a breakpoint

Right-click on a statement where a breakpoint has been set, and then select Disable Breakpoint from the shortcut menu.

Enable a breakpoint

Right-click on a statement where a breakpoint has been set, and then select Enable Breakpoint from the shortcut menu.

Remove a breakpoint

Right-click on a statement where a breakpoint has been set, and then select Remove Breakpoint from the shortcut menu.

Configure a breakpoint

Right-click on a statement where a breakpoint has been set, and then select Breakpoint Properties from the shortcut menu.

Step over a statement

Select Step Over from the Debug menu, or press F10.

Step into a function

Select Step Into from the Debug menu, or press F11.

Step out of a function

Select Step Out from the Debug menu, or press Shift+F11.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.121.209