I'm not clear on who wants to flash 10 morphs,
but if you do this
m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75);
openInWorld]
then try this:
m do: [ :e | e flash]
The standard version of #flash *occasionally* causes a visible
change in the first morph, but I never notice a change in any of
the others.
The 100 ms delay version makes all of the flashes clearly
noticeable, in sequence.
A 10 ms delay in #flash makes them mostly (but briefly)
detectable.
I suspect if you really want to flash 10 morphs, you may do well
with a rather different approach.
Cheers,
Bob
On 8/18/13 9:10 PM, Levente Uzonyi
wrote:
On Sun, 18 Aug 2013, Chris Muller wrote:
The trouble with using an alarm is if
#flash gets called again before
the alarm fires, it will think its negated color is its normal
color
and add yet another alarm to reverse it again, leaving it in the
flashed color.
Could you (or Levente) elaborate by why it might not be a good
idea?
IIUC if you flash multiple Morphs, the delays will stack. So
flashing 10 morphs will cause a second delay.
Levente
I think describing use-cases really helps understand context.
For me,
I use flash as a debugging tool, I open an inspector on a Morph
and
type "self flash" and press and hold Command+d to DoIt. I don't
really need the Delay since the key-repeat takes care of it..
On Sun, Aug 18, 2013 at 3:32 PM, Marcel Taeumel
<marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
Yup, not the best idea. That's why I
voted for the use of Morphic Alarms. :)
Best,
Marcel
--
View this message in context:
http://forum.world.st/computers-too-fast-these-days-tp4704067p4704077.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.