Thank you, I wanted to understand how this works. And I also understood how
it comes that the sample (original clock) does not fail, as the
'draw_background' definition appears after the first call. It goes fine
because the 'animate' method executes the block later. Remove the animate
and it fails, but if you also move the definition in the beginning of block
it wroks.
Shoes.app :height => 260, :width => 250 do #BLOCK-1
animate(1) do #BLOCK-2
clear do
draw_background # if BLOCK-2 is executed the first time BLOCK-1
executes, this call fails
end
end
def draw_background
# do something
end
end
-Jean
On Fri, Aug 22, 2008 at 9:00 AM, _why <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 20, 2008 at 08:38:04PM +1000, Bluebie, Jenna wrote:
> > It is possible to both change the binding, and run a proc in some other
> place
> > without changing it's binding permanently (as with instance_eval and
> > friends) for much hacky fun. Markaby and Shoes make use of that freedom a
> > lot to do a lot of their trickery.
>
> However. One caveat. Shoes does no instance_eval generally, since
> it turned out to be so confusing in Markaby. Maybe very early on,
> but not now.
>
> How was it confusing? Well, instance_eval changes `self`. Which
> means instance variables won't pass from one block to the next. It
> just makes things weird.
>
> So, Shoes keeps track of which slot is open for editing and, when an
> element is added, it gets added to the open slot.
>
> Shoes.app do
> stack do
> flow do
> para "Name" # the 'flow' is the open slot
> edit_line # so these get added to that
> end
> end
> end
>
> The `self` throughout all of this is the Shoes::App object. So,
> when you set instance vars, they get set on the Shoes::App. (Unless
> you're in a url-style Shoes subclass. Then they get set on an
> object of that type.)
>
> _why
>
