Delay without the Delay O.o

[Warchamp7]

Is it possible to make the arrow keys recieve a delay when being pushed down. I currently have a loop that constantly updates the screen but I want the arrow keys to have some sort of delay.

code:

loop     Interface     View.Update end loop

Interface is the procedure that draws everything. How can I incorporate arrow keys into this so that they don't change my variable value so fast:

code:

Input.KeyDown (chars)     if chars (KEY_DOWN_ARROW) then         if MainBoxOption = 4 then             MainBoxOption := 1         else             MainBoxOption := MainBoxOption + 1         end if         elsif chars (KEY_UP_ARROW) then             if MainBoxOption = 1 then                 MainBoxOption := 4             else                 MainBoxOption := MainBoxOption - 1             end if         end if

Basically, it's a menu with 4 options, it checks if when pressing up, if the option is 1, to go to the bottom to number 4, etc
I want a delay between the movement so it doesn't scroll from 1 to 4 in a split second, while still maintaining the "Drawing" loop working constantly

[SNIPERDUDE]

yes it is possible, but it requires a bit of coding. All you need to do is create a for loop (in a procedure) that counts how ever many times you want (so the proc is called every time the prog cycles through the loop) and have a boolean that resets after the loop is done; so the user can only press the button every time the counter resets.

For Example:

code:

var intCount : int := 0 var blnEnabled : boolean := true proc Counter     intCount += 1     if intCount > maxInt then         blnEnable = true         intCount = 0     end if end Counter proc Keys     if blnEnable = true then         %Whatever your key commands are go here         blnEnable = false     else         Counter     end if end Keys loop     Keys     %w/e else end loop

[Clayton]

So what happens on a really slow system? Instead, look into using Time.Elapsed().

[Albrecd]

Or you could always put the action in a process and fork it when the button is pressed. Then you can have a delay in the process and it won't affect your background.

That's right, I said process

[Cervantes]

Don't even joke about such things!

[Carey]

Processes are evil. I admit it is sometimes the best way, but only for something that is non-critical to the execution of the program, like drawing a non-improtant graphic.

[Dan]

Carey @ 14th June 2007, 9:05 am wrote:

Processes are evil. I admit it is sometimes the best way, but only for something that is non-critical to the execution of the program, like drawing a non-improtant graphic.

Only if you don't care when thos graphics are drawn. With turings limited to no control to syncrioize process execution you basically will have graphics that draw at random times (unless you understand process enought to make your own syncoriztion system). With most projects peoleop are doing in truing process are relay not needed and it gets them in to bad habits.

Process == bad with out synchronization of some kind.

[Warchamp7]

Quote:

Processes are evil. I admit it is sometimes the best way, but only for something that is non-critical to the execution of the program, like drawing a non-improtant graphic.

Exactly lol XD

But your idea sounds good Sniper, I'll give it a shot =D

[rizzix]

Concurrency requires a different mindset (something most of us are not really used to). You need to know exactly what you can put in a different thread and what you should avoid running concurrently.

For most cases you don't really need it.

And yes as Dan said, synchronization is the key. (This is a tricky task specially since you need to avoid the "deadlock")