Greetings:

I'm getting an error message about an improper format for a GUID in the following sub. It is located in the Admin form; I've worked my way halfway through Chapter 12, Selecting Data. The error is a System.FormatException, "Guid should contain 32 digits with 4 dashes".


Private Sub lvwRoles_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles lvwRoles.Click
        'initialize a new instance of the business logic component
        objRoles = New WroxBusinessLogic.WBLRoles(strCompany, strApplication)

        Try
            'get the specific role selected in lv control
            objDataSet = objRoles.GetRole(New Guid(lvwRoles.SelectedItems.Item(0).Tag.ToString)) 'error occurs

The error occurs on the first step of the debugger after it arrives at this line. The functionally similar sub:

Private Sub lvwUsers_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles lvwUsers.Click
        objUsers = New WroxBusinessLogic.WBLUsers(strCompany, strApplication)

        Try
            'get the specific user selected in the lv control
            objDataSet = objUsers.GetUser(New Guid(lvwUsers.SelectedItems.Item(0).Tag.ToString))

works just fine. The debugger steps through all called procedures in the business logic, data access, and base components. In the problem sub above, apparently none of those procedures are even called, as the debugger goes straight to the Catch line from objDataSet. I've looked for typos in the constructor for WBLRoles, but haven't found anything. Any other suggestions?

Thanks!

The Tag property contains the GUID? Did you try to check the value and see if that really is the case, and it isn't looking at something else?

Brian

Thanks Brian
Yes, the tag references the guid RoleID, similar to the other listview click events. The code is straight out of the book. My real question at this point is what the debugger is telling me by just bouncing off that line, and going straight to the Catch block. When I take a working listview click event, and then screw up the code on purpose, the debugger works it way through all the referenced procedures until it hits the error, and then passes the error message back to the calling procedure. What does it mean when the debugger goes straight to the Catch block? The obvious answer is that the error is in that line, but that line of code is identical to the code in the download, its functionally similar to the other listview click events, and there are no syntax errors in it. So, what is the debugger telling me?

Hey,

The debugger isn't trying to tell you anything per se. The catch line handles errors; that's its functionality. The lines grouped in the try section; one of them have an error which the catch handles and does something appropriately. Is that what you mean?

Brian

Try setting a breakpoint on this line of code:

objDataSet = objRoles.GetRole(New Guid(lvwRoles.SelectedItems.Item(0).Tag.ToString))

When you encounter the breakpoint, query the value for lvwRoles.SelectedItems.Item(0).Tag.ToString in the Command window to see what it contains.

Thearon

Thanks Thearon, that gives me something I can work with. The command line query shows that this expression works out to the role name, e.g. "manager", in the problematic sub. In a functional listview click event, this expression returns a guid. That gives me a clear idea how to fix this.

But I'm still curious...why doesn't the debugger step through all the called procedures until it gets to the error? This jumping straight to the Catch block doesn't give much to work with.
Thanks again

Is the objRoles instantiated? Try commenting out the Try...Catch block and let Visual Studio catch and display the error to see what it reports?

Thearon

Hey,

That is the nature of catch though; an error will keep trying to propogate up the call stack until it is caught; only when it is not caught, does the error show directly in the Visual Studio designer. You have to remove the try catch block (or comment out) as mentioned above.

If you look at the call stack, it does show the lines executed in the order they fire, and you can trace it back some that way.

Brian

Thankyou, I will look at those things to help me understand the debugger. Using the command line to evaluate the problem line of code pointed to a logic error in the LoadRoles function, where I'd typed in "RoleName" instead of "RoleID" in an AddParameter line. I learn a lot more debugging my mistakes than I do from typing them in in the first place. Thanks for your help.

Sure, the Immediate Window does help in identifying these things also. it is another useful tool, as well as the autos window which shows the immediate variables in scope.

Brian