Topic: Debug watch-variables panel displays structured data types badly

Jeff,

When I add a structured data type to the watch-variables panel, the watched-variable initially displays neatly but, when I then click on the tiny [+] symbol to expand the full variable structure the display overwrites text on top of text.

The data structure with which I discovered this is as follows.

      MODULE FILES
C     ------------
C     jw 22-02-12 draft
C     jw 03-03-12 last amended
C     --------------------
C     FILES
C     --------------------
C     Filename
C     Flags
C     Fortran unit, file menu ID, Menu-select IDs R, W, Wnew

      TYPE ::  FILE
         CHARACTER   :: NAM*128
         LOGICAL     :: NAMed, Open
         INTEGER     :: LU,
     +                  id, R, W, WN
      END TYPE
     
      TYPE(FILE)     :: InF, OuF

      END MODULE Files

The watch-variable window displays the data structure for the variable, [ InF ], well enough, but it can't expand to display data contained within that structure without making a mess.

If I could attach a screenshot file on this forum I would do but, as I can't, I'll email it to you.
----
John

Re: Debug watch-variables panel displays structured data types badly

I've emailed a couple of screenshots.
---
J.

  • jeff
  • Administrator
  • Offline

Re: Debug watch-variables panel displays structured data types badly

John,

Thanks for the screenshots.  There certainly does seem to be a nasty drawing problem.  I'll look into it, but a fix probably won't make this week's predicted release of 1.26.  Furthermore, the Insight debugger may be upgraded to a more recent version in the next release cycle or two.  That said, I'll have a look in the current code to see if I can identify what's gone wrong.

Jeff Armstrong
Approximatrix, LLC

Re: Debug watch-variables panel displays structured data types badly

Jeff, please look again at the second of the two screenshots I sent you.  Apart from the text walking over other text, as already reported, there's also something else there, a second gremlin. which I hadn't noticed before.

In the particular example shown on the screenshot,
the debugger display shows the contents of a structured
variable called  [ InF ] . 

This contains, inter alia, a sub-variable called  [ nam] .

It so happens that, in my program, [ InF%nam ] stores a file pathname.
In the example shown, the stored value was,

    'G:\InStruct\Tests\Sav.zzz'

However, please look at what the debugger reports it to be. 
It reports the stored value wrongly as,

    'G:\\InStruct\\Tests\\Sav.zzz' .

I have double-checked to ensure that there isn't a fault in my program, causing the double '\\' to be stored in this variable, and I can't find one.  Furthermore, and this fully confirms it, I have inserted a debug statement to print InF%nam to the screen, and it prints the correct value, of 'G:\InStruct\Tests\Sav.zzz'.

Seemingly, the debugger is reporting an incorrect value for this structured variable.

I can't think that the source code of my program can be causing this but, in case it helps to know this, the source code includes some strong concatenation using the '//' operator.  This does not happen in any code near the place where this debug reporting error occurs, however.  Here is the fragment of code that stores a value in   [ InF%nam ] :

      InF%NAMed = .FALSE.
      InF%NAM = REPEAT(' ',128)
      CALL dwgfil('SAVE file name', InF%NAM, '*.*')    ! DISLIN
      InF%NAM = TRIM(AdjustL(InF%NAM))

The call to a DISLIN procedure displays a filename-selector dialog box, with a prompt string, and returns a file pathname to the calling program.  As you see, there is nothing in this that should cause the problem.  Note also that the pathneme selected in the example I gave includes my "G:\" virtual drive abbreviation.
----
John

  • jeff
  • Administrator
  • Offline

Re: Debug watch-variables panel displays structured data types badly

John,

The double backslashes are displayed due to the C-centric nature of the debugger.  In C, a backslash would be an escape character.  I would guess that the debugger is displaying double backslashes to make it clear to the developer that it isn't referring to an escape sequence.  If your path had a tab character in it somehow (not possible I would guess), you'd probably see a "\t" in the path where the tab should be.  I don't think it's a problem, just something that the developer should be aware of.

Jeff Armstrong
Approximatrix, LLC