Forum Discussion

matt's avatar
matt
Occasional Contributor
15 years ago

Error viewing locals or inspecting an array of objects during debug

Using the code included below, set a breakpoint on the "Log.Message" line in function "bar". Run "bar". View the Locals window and expand array "a". The value for the first item will be:




"Error: Could not convert variant of type (OleStr) into type (Dispatch)"




Notice that you can correctly inspect the custom object in variable "b"...just not when it is included as an item in an array. Version of TC is 7.5.





function foo()

{

  this.name = "myname";

}







function bar()

{

  var a = new Array(1);

  var b = new foo();

  

  a[0] = b; 

  

  Log.Message(a[0].name);  

}





8 Replies

  • Matt,



    I'm not seeing the error message you're describing.  I'm also on TC 7.5.  When evaluating a[0].name, it's returning "myname".  Also Log.Message is returning "myname" in the log.
  • matt's avatar
    matt
    Occasional Contributor
    Thanks for trying, but I don't think you are doing the same thing as me. I am talking about the Locals panel/window that is displayed (along with the Call Stack, Watch List and Breakpoints). If you set the breakpoint where I stated (on the Log line) and look at the Locals window, you should see the error I am talking about when you click the + sign to expand the variable "a". The error actually shows in the Value column for index [0].



    The same error can also be seen if you highlight the variable "a" in the code window, right click, and select Debug -> Evaluate. This brings up the Evaluate dialog for expression "a". If you then click Inspect, the Inspect dialog appears. The Inspect dialog shows that for array index [0] the value is "Error: Could not convert..." (same error as I mentioned).




    I guess I should have stated explicitly that the problem is with debug mode and the Locals window. The problem does not impact the actual use of custom objects inside arrays. These work fine, and (as you said) the expression "a[0].name" does log correctly and can be explicitly evaluated.

  • matt's avatar
    matt
    Occasional Contributor
    Not sure...your image is coming up blank in my browser. I can only assume that you are offering visual proof that either the problem does not happen for you or that you are now seeing the same issue as me.



    I have a co-worker who also has problems inspecting objects in debug mode on his install of TC 7.5. However, I just tried installing TC 7.5 on a clean virtual machine, and the problem does not happen. So the problem is seen in certain environments. Perhaps it is related to numerous upgrades of TC (going back to version 5) on my primary work machine? I am going to try uninstalling everything and reinstalling. Maybe this will fix the issue.

  • matt's avatar
    matt
    Occasional Contributor
    I uninstalled TC 7.5. I also had a version of TC 6 on my system, that I no longer use. I uninstalled it too. I also uninstalled MS Script Debugger. I then reinstalled MS Script Debugger followed by TC 7.5.



    Problem Solved! 




    A side benefit is that debugging (stepping line by line) is much faster now too. It used to take a few seconds (at least) to wait for control to return to the debugger when stepping over even the most basic line of code.

  • Glad it's resolved.  I was trying to show you that I was unable to see your problem.



    My debugging is still slow - I may just re-install MS Debugger...
  • This sounds like a problem that was mentioned in the old newsgroups. Do the problem machines have Visual Studio 2008 installed on them? If so, the problem is due to the fact that VS installs its own version of the script debugger that does not work so well with TC.



    In the post that I saw, the recommended solution was to rename the folder that the VS debugger is in ("C:\Program Files\Common Files\microsoft shared\VS7Debug") and reinstall the old MS Script Debugger. I think that's a pretty poor solution if you still want to work with VS. I also saw some references to the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{78A51822-51F4-11D0-8F20-00805F2CD064}\InprocServer32

    It seems that this key can be used to switch between the two debugger versions. It contains the path to a file called "pdm.dll". The old version is usually installed in the Windows\System32 folder, while the VS version is in the path I mentioned earlier. I tried changing this for the first time yesterday, and it does seem to work OK.




    Also, while I still had the VS version active, I found that debugging in TC was very slow after I had used VS. If I hadn't used VS since rebooting, then TC debugging was not slow, but it did have the problems mentioned in the first post of this thread.

  • matt's avatar
    matt
    Occasional Contributor
    Interesting...I do have VS 2008 installed on the machine where the problem is seen. Thanks for the additional information.