Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-1805

SwingBuilder does not intialzie properties in code order

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.0
    • 1.1-beta-1
    • groovy-jdk
    • None
    • Patch

    Description

      According to Romian GUY
      <blockquote>
      While working on GroovyConsole, I have run into a weird behavior of
      the SwingBuilder. Here is what I tried to do:

      frame(
      size:[500,500],
      locationRelativeTo:null,
      // ...
      )

      Calling JFrame.setLocationRelativeTo(null) centers the JFrame on the
      screen. Obviously, this work only when the appropriate size was set
      on the frame. This piece of code works just fine on Mac OS X but
      fails on Windows XP. In that case, the window appears at the bottom
      right of the screen. This looks like something that could be caused
      by an out-of-order execution of the setters in SwingBuilder. Is there
      any reason why the SwingBuilder would invoke setLocationRelativeTo
      (null) before setSize(500, 500)?
      </blockquote>

      Indeed, the propeties are initialized according to the names has order, not the order they are specified in the source code. Here is a test case....
      <code>
      sb = new groovy.swing.SwingBuilder()
      f = sb.frame(
      size:[500,500],
      locationRelativeTo:null,
      // ...
      )
      f.visible = true
      sizeFirst = f.location
      f.visible = false
      f.dispose()

      f = sb.frame(
      locationRelativeTo:null,
      size:[500,500],
      // ...
      )
      f.visible = true
      sizeLast = f.location
      f.visible = false
      f.dispose()

      assert sizeFirst != sizeLast
      </code>

      Really they should result in different locations, but in 1.0 they result in the same location.

      There are two possible solutions, one is a quick and dirty hack to make locationRelativeTo a special case property, and this affects swingbuidler only. The other one is to make the map notation remember the order of the addition of the key value pairs, via a LinkedHashMap. These correspond to QuickHackPatch.txt and RobustHackPatch.txt (the latter involved updating the test cases as well)

      Attachments

        1. groovy-1805-unit-test.txt
          1 kB
          Daniel Ferrin
        2. QuickHackPatch.txt
          0.9 kB
          Daniel Ferrin
        3. RobustPatch.txt
          4 kB
          Daniel Ferrin

        Activity

          People

            shemnon Daniel Ferrin
            shemnon Daniel Ferrin
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: