> I guess you ask this for removing the DemoApp from the list when it's
> closed, but maybe you could just not use that class and eval the code
> straight from the main app? And if the code contains Shoes.app, then
> run it, else eval it in a new window ( window { eval @e.text } )
Interesting... so this doesn't quite work, because within the window @e is
not defined. This is definitely not what I expected... I guess this is an
example of the type of funkiness with blocks that _why warned about.
This is pretty weird though, because as I understood it the funkiness had to
do with the definition of self within the block, but regardless of self I'd
expect there to be a closure so @e would be available. I can work around
the problem by defining a local variable reference to @e, so while
window {eval @e.text}
doesn't work
e = @e; window {eval e.text}
does. I guess instance variables are looked up on self, so closures don't
work in quite the way I'd expect when it creates a new window, but I can
work around it.
That said... this doesn't end up solving my problem. I still haven't found
a way to get or register a callback for when that window closes, and if I
try to close an already closed window Shoes crashes, just the same as when I
tried to close an already closed App.
However, I did discover that Shoes has a method for seeing what apps are
currently open... Shoes.APPS. By using this to compare against my list, I
can avoid trying to close apps twice. I haven't figured a similar way to do
bookkeeping for windows.
-Kevin
