Repeat Forever - Not Working

[Googie85]

I cannot get this following code to work:-

Code: Select all

on mouseUp
     repeat until the mouseClick
            set the visible of image SolidBlue to true
   wait 0.1 seconds
   set the visible of image SolidBlue to false
   set the visible of image SolidRed to true
   wait 0.1 seconds
   set the visible of image SolidRed to false
   set the visible of image HalfBlue to true
   wait 0.1 seconds
   set the visible of image HalfBlue to false
   set the visible of image HalfRed to true
   wait 0.1 seconds
   set the visible of image HalfRed to false
   end repeat
end mouseUp

I have tried everything and it still dosnt want to work.

Many Thanks,

Matthew.

[[-hh]]

Matthew,

when the mouse is up then the mouse has already clicked (the mouseclick is true) and it stops,
"repeat until the mouse is down" would work.

This does the same non-blocking (you could use the half second of each loop for better things than waiting).

Code: Select all

local i0, ii="solidred,solidblue,halfblue,halfred"

on mouseUp
  put "halfred" into i0
  switchit 0
end mouseUp

on switchIt x
  add 1 to x
  if x=5 then put 1 into x
  hide img i0
  if the mouse is down then exit switchit --> see note
  put item x of ii into i0
  show img i0
  send "switchIt x" to me in 100 millisecs
end switchIt

Note. If it should stop after "halfred" only, then use

Code: Select all

if the mouse is down and i0 is "halfred" then exit switchIt

H.
[Edit: Corrected to use different images, saw this too late for my first answer.]

[jacque]

More about this:

http://www.hyperactivesw.com/polling.html

[[-hh]]

@jacques
Your memo/link is *very* useful for a "dragging-scenario".

But I wonder how you conclude from a loop fired with "mouseUp" and a stop-rule of "clicking" to have a "dragging-scenario"?

[jacque]

@jacques
Your memo/link is *very* useful for a "dragging-scenario".

But I wonder how you conclude from a loop fired with "mouseUp" and a stop-rule of "clicking" to have a "dragging-scenario"?

The main idea is that scripts should not poll the mouse state unnecessarily. In loops it locks up the CPU, but in this case something else happens. The state of the mouse is only recognized at the exact moment the evaluation occurs. A fast click in a long handler may not occur at that point in the script and the handler won't know the mouse has been clicked.

Your example handlers are almost exactly what should be done, except for adding a flag to track activity. Something like this:

Code: Select all

local i0, ii="solidred,solidblue,halfblue,halfred"
local sFlag

on mouseUp
  put not sFlag into sFlag
  if sFlag then
    put "halfred" into i0
    switchit 0
  end if
end mouseUp

on switchIt x
  if sFlag = false then exit switchIt
  add 1 to x
  if x=5 then put 1 into x
  hide img i0
  put item x of ii into i0
  show img i0
  send "switchIt x" to me in 100 millisecs
end switchIt

[[-hh]]

@Matthew
As I see know, the question is in "Android Deployment", thus probably touchscreen things come in. I've not enough knowledge of that, so use my answer as a hint only to think about blocking and non-blocking loops. Jacque's answer may also even more applicable from that reason.

@jacque
I'm not convinced by the flag-method to be "the" solution any more. Depends on the situation, platform (incl. HTML5) and hardware (incl. Raspi/slow machines) by the "beat" of the loop. [Especially the usual Mac user behaviour to doubleClick or fast click twice is a hurdle for that, even if one adds other handlers like filtering pendingMessages, indicate the flag's state and so on].
For myself I use also the "poll mouse <in time>"-method because I really can't say one is generally better than the other.

[Ray@LinkIt.Com]

How about this:

on mouseUp
repeat forever
set the visible of image SolidBlue to true
wait 0.1 seconds
set the visible of image SolidBlue to false
set the visible of image SolidRed to true
wait 0.1 seconds
set the visible of image SolidRed to false
set the visible of image HalfBlue to true
wait 0.1 seconds
set the visible of image HalfBlue to false
set the visible of image HalfRed to true
wait 0.1 seconds
set the visible of image HalfRed to false
if the mouse is down then exit repeat
end repeat
end mouseUp

[[-hh]]

This works (as I said above), but *NOT* to do that was exactly our proposal.
Using "send <in time>" takes only the CPU time the animation needs, the rest is taken by the system. Your variant, the "wait", stops for the whole time everything else: No watch is running, no other screen update, everything is blocked by doing "nothing" (while waiting).

For example see the difference by that:
Create a field, set locktext of it to true and set its script to the following (= a "Text-clock"):

Code: Select all

local runShow=false

on mouseUp
   put not runShow into runShow
   showTime
end mouseUp

on showTime
   if runShow then
      put the internet date into me
      send "showTime" to me in (1000 - the millisecs mod 1000) millisecs
   else put "Click me for a digital clock" into me
end showTime

Then watch what this "Text-clock" does ...
(a) ... with your script: it stops until you click again (outside of its rectangle).
(b) ... with one of our scripts above: the clock goes on during the animation.

Our non-blocking scripts are proposals, nothing more.

p.s.Click the field only ONCE each time

[Ray@LinkIt.Com]

Whoops - I missed the non-blocking idea in your proposal. Sorry about that. The use of the send command seems the way to go if a non-blocking handler is the goal.