Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Interface bug with frames

    Dear Statalist users,

    I am running across an interface error that seems to be a bug in Stata 17 when using the frames command. I would like to double check that the problem is not local to my machine before submitting it as a bug to the Stata technical team.

    The issue is related to using
    frame copy command with replace option when frame to be rewritten is selected as the currrent frame.


    First off, running the following code in one go will produce no error.

    Code:
    clear all
    frame create auto
    frame auto: sysuse auto
    
    frame copy auto default, replace
    By no error, I mean you will be seeing the contents of auto.dta loaded into the default frame, and because the default frame is the one that is currently selected, you should be seeing the list of variables in "Variables" window as well as the actual data in Data Viewer. Do not close the Data Viewer; keep it open.

    Now run it again but in two pieces.

    Code:
    clear all
    frame create auto
    frame auto: sysuse auto
    At this point, the default frame is empty, therefore you should not be seeing any variables etc. Data Viewer is also empty. Next immediately run the last line.

    Code:
    frame copy auto default, replace
    Normally, the expected behavior would be to see the contents of
    auto.dta to be loaded into the default frame and visible as we are essentially still looking at the default frame. The data is in fact loaded, yet the "Variables" section on the main screen is empty (not showing any variables). Also look at the data viwer as well to see it empty. Just to make sure there is in fact auto.dta content loaded, you may summarize the data. It's loaded yet Stata is not showing them properly on the interface.

    Click image for larger version

Name:	Capture.PNG
Views:	1
Size:	130.1 KB
ID:	1613541


    The issue is not unique to the default frame; so I could just as well load auto.dta to the default frame, switch to another frame and try to copy data from the default frame to the current frame with replace option. The problem seems to be isolated to running frame copy ..., replace by itself.

  • #2
    Your example is reproducible on Stata 16.1. I think you found an undiscovered problem, or if it is intended behavior, a very unintuitive result. It is worth reporting to Stata Technical Services.
    Code:
    . clear all
    
    . frame create auto
    
    . frame auto: sysuse auto
    (1978 Automobile Data)
    
    . frame dir
      auto     74 x 12; 1978 Automobile Data
      default  0 x 0
    
    . frame
      (current frame is default)
    
    .
    Code:
    . // the following produces the results pictured in post #1
    . frame copy auto default, replace
    Code:
    . // nothing changes in the display by running these commands
    . frame dir
      auto     74 x 12; 1978 Automobile Data
      default  74 x 12; 1978 Automobile Data
    
    . frame
      (current frame is default)
    Code:
    . // this corrects the display!
    . frame change default

    Comment


    • #3
      The results in post #2 were produced by selecting groups of lines in the Do-file Editor and running the selections separately. The same results obtain if the selected lines are instead copied and pasted into the Command window in groups. However, if the lines up to the frame copy command are copied as a single group and pasted into the Command window, the results are again anomalous, whereas when they are run as a single from from the Do-file Editor, the display is correct. Very odd.

      Comment


      • #4
        Gorkem Aksaray and William Lisowski thank you for the the detailed description of the problem. We have reproduced the issue and are now investigating. I will report back when I have more information.

        Comment


        • #5
          This was indeed a bug that prevented the user interface from updating properly after frame copy replaced the current-working frame. Look for this to be fixed in the next update.
          Code:
            
           . frame change <current working frame>
          is a valid work around until the update is released.

          Comment

          Working...
          X