The method `build()` sets the Closure's delegate to `this` (`this` being the instance of SwingBuilder) before it calls the Closure, so the methods `frame` and `menuBar` indeed end up being invoked on the SwingBuilder instance.
Cheers, Dinko On 8 April 2015 at 02:05, Ralph Johnson <[email protected]> wrote: > I'm working a program that was mostly written by someone else. > > Some of the code I didn't write has things like > > public Object windowSpec() { > > return { > > def windowFrame = frame(attributes+[pack: true, > defaultCloseOperation: windowCloseAction]) { > > menuBar(this.menuBarSpec) > > widget([widget: builder.build(contentViewSpec),id: 'content']) > > } > > windowFrame.addWindowListener(this) > > windowFrame > > } > > } > > > which gets called from a method that is sort of like > > > protected buildView() { > > builder.edt { > > view = builder.build(this.windowSpec()) > > } > > } > > > How can this work? In particular, when windowSpec calls methods defined by > the SwingBuilder such as frame() and menuBar(), why are those considered > methods on the SwingBuilder and not on the class that contains the class > that contains this code? > > There are a bunch of subclasses of the class with this code that works > correctly, but one where it doesn't, and I'm trying to figure out why. But > then I realized that I don't understand how it works at all. Does the > method build() change the closure so that it will look in the SwingBuilder > for those methods? > > > -Ralph Johnson
