Multithread/Background function execution in Rev?

[nfeasey at utpress.utoronto.ca]

Ok guys, you have pointed me into the right direction and I thank you very
much for your input. The wait ... with messages did the trick for me in this
instance.

However, here is something interesting.  Take the following code within a
tabbed button...
 
global pNewItem, gvarea

on menuPick pNewItem, pOldItem
    
  switch pNewItem
  case "Setup"

    put 1 into gvarea
    disable group gScroll
    show button bBubbleChooseLT
    wait 2 seconds with messages
    hide button bBubbleChooseLT
    break

  case "Track"

    put 2 into gvarea
    disable group gScroll
    enable button bSearch
    show button bBubbleChooseLO
    wait 2 seconds with messages
    hide button bBubbleChooseLO
    break

  case "Report"

    put 3 into gvarea
    disable group gScroll
    enable button bSearch
    show button bBubbleChooseLO
    wait 2 seconds with messages
    hide button bBubbleChooseLO

  end switch
  
end menuPick

Looks ok to me, however, the buttons on am showing or hiding NEVER APPEAR.
Switching between the index tabs is INCREDIBLY SLOW.

Any thoughts?  Can anyone duplicate this behaviour?

N

-----Original Message-----
From: Dar Scott [mailto:dsc at swcp.com] 
Sent: Tuesday, July 29, 2003 6:07 PM
To: use-revolution at lists.runrev.com
Subject: Re: Multithread/Background function execution in Rev?



On Tuesday, July 29, 2003, at 02:59 PM, nfeasey at utpress.utoronto.ca 
wrote:

> show button "myButton" with visual effect dissolve
> wait 2 seconds
> hide button "myButton" with visual effect dissolve

The two seconds we can do something about.

However, I don't know how to set up things to handle field events 
during a visual effect.

Scott mentioned blendLevel twice and I hinted at it.  Here is how a 
first pass at that might work.  Make a handler to start off the whole 
thing.  It might send the message "blendIn 98" in 20 ms which sets the 
blend level and sends off another "blendIn n" in 20 ms where n is the 
decreased amount, except when it gets down to 0 when it sends off 
"blendOut 2" in two seconds.  The blendOut n is increases the blend to 
100 where it stops sending messages to itself.  Fiddle with the blend 
steps and the delays.

This has the requirement that you make an image.

If you want the same timing on all platforms, then set the new blend 
level not by parameter, buy by the time since the start handler ran 
(save away the ms or the long seconds).  In general, this is the better 
approach because it adapts to slower computers and other things going 
on.

If you find creating an image to be a problem, you might try putting an 
image in front of the help field that has the color or pattern of the 
background and fade it out and in (backwards from above).  This will 
work if the help is computed or comes from a list.  Or you might decide 
that flying in and out is just fine.

If the user can switch cards, then you may want a way to abort the 
process (see cancel).  If you don't bother, then make sure the handler 
refers to all objects by long ID or relative to 'me'.

You want to make sure the messages don't block mouse and key events, so 
put your send at the end of your repeated handler.  (If you need exact 
timing or compute delays, not likely here, then there are exceptions.)  
Sent messages and built-in callback messages are handled before mouse 
and key events it seems, so it is possible to overload things if you 
don't put good delays in sending messages.

Again, I apologize for not noticing the visual effect need and 
responding as though this was simply send off a message to hide the 
button in two seconds.

Wouldn't it be cool if all controls had blendLevel?

Dar Scott




_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution