Simple Logic

avi_dave

Someone be my guess and help me out with this simple logic, please,

button_event [button.input.device,button.input.channel]
{
push:
{
// I want to execute a string
}
hold [50]
{
//but if that same input is held for more than 5 secs I dont want the first statement to execute I want to skip to a second statement and execute that. (Im doing a save on the hold of the button but on the touch execute the preset)
}

Hedberg

I think this would work

button_event[dvtp,nChannel]
{
  push:
  {
    do_something_on_the_press()
    this_is_pressing = 1
    wait 50
    {
      if(this_is_pressing)
      {
        do_something_if_held_5_seconds()
      }
    }
  }
  release:
  {
    this_is_pressing = 0
  }
}

You could do it with a timed wait and cancel the wait upon release, also. You can do it with hold:, I'm sure, but that would not be my preference. I prefer hold for something that's repeated (like a string to a device to change volume or something), but for a simple conditional delay I would prefer a wait or named wait and release:

vining

Try this.

button_event [button.input.device,button.input.channel]
     {
     push:
	  {
	  wait 60 'See_If_Hold_Delay'
	       // I want to execute a string
	  }
     hold [50]
	  {
	  cancel_wait 'See_If_Hold_Delay'
	       //but if that same input is held for more than 5 secs I dont want the first statement to execute I want to skip to a second statement and execute that. (Im doing a save on the hold of the button but on the touch execute the preset)
	  }
     }

GSLogic

You could get real fancy and have one button do many different command based upon how long you hold the button.

BUTTON_EVENT[dvTP,btArray]
{
  PUSH:
  {
      nHoldVar = 0;
  }
  HOLD[30]: //three seconds
  {
      nHoldVar = 1;
  }
  RELEASE
  {
      if(nHoldVar == 0)      
      {
            //do PUSH command stuff
      }
      else
      {
            //do HOLD command stuff
            nHoldVar = 0;
      }
   }
}

avi_dave

ahaaaa thx peoples really helpfull, Im going twist a bit, understand what I need now

vining

GSLogic wrote:

You could get real fancy and have one button do many different command based upon how long you hold the button.

I thought about posting the same thing but I didn't like the idea of requiring a release to execute the hold event. I like a hold event to happen during the hold itself there by letting me know it's time to release.

Hedberg

vining wrote:

GSLogic wrote:

I thought about posting the same thing but I didn't like the idea of requiring a release to execute the hold event. I like a hold event to happen during the hold itself there by letting me know it's time to release.

I think you're right -- it's better to do with a hold.

GSLogic

vining wrote:

I thought about posting the same thing but I didn't like the idea of requiring a release to execute the hold event. I like a hold event to happen during the hold itself there by letting me know it's time to release.

I also use one like you posted, it all depends on the application.

The one I like to use is the HOLD-RELEASE with a TIMELINE. As you RELEASE, the TIMER flags the hold time, so it's really unlimited events set by how long you hold the button.

ericmedley

GSLogic wrote:

I also use one like you posted, it all depends on the application.

The one I like to use is the HOLD-RELEASE with a TIMELINE. As you RELEASE, the TIMER flags the hold time, so it's really unlimited events set by how long you hold the button.

I think I'd use the 'release' as the push. and then trap the code in the release of the hold happens.

So.

BUTTON_EVENT[]
{
RELEASE:
{
IF(!DONT_DO_IT_FLAG)
{
// GO AHEAD AND DO IT
}
} // END RELEASE:

HOLD[50]:
{
// OKAY DO THE HOLD STUFF
// DONT_DO_IT_FLAG=1
WAIT 50 // reset the flag after event is done
{
DONT_DO_IT_FLAG=0
}
}
} // END BUTTON_EVENT


Kind of 'old skool' but it'd work...

NMarkRoberts

avi_dave wrote:

but if that same input is held for more than 5 secs I dont want the first statement to execute I want to skip to a second statement and execute that.

Strictly speaking that is of course impossible. "Don't do this if that is going to happen in 5 seconds?"

DHawthorne

NMarkRoberts wrote:

Strictly speaking that is of course impossible. "Don't do this if that is going to happen in 5 seconds?"

My solution is just not to use the PUSH. Put all the action on the RELEASE. If the button is just tapped, it's indistinguishable from a PUSH; it happens too fast. You can set a flag in the HOLD that will prevent the RELEASE event if the HOLD is executed.

DEFINE_VARIABLES

CHAR bHoldFlag

DEFINE_EVENTS

BUTTON_EVENT[dvTP, nButtons]
{
    HOLD [100] :
    {
        bHoldFlag = TRUE
        // Do hold action here
    }
    RELEASE :
    {
        IF(!bHoldFlag)   
        {
            // do "PUSH" action here
        }

       bHoldFlag = FALSE    // reset flag
    }
}

The RELEASE will only take action if the HOLD did not. If you don't trap it like this, both will happen; likewise, if you put something on the PUSH, it will also happen every time.

GSLogic

DHawthorne wrote:

My solution is just not to use the PUSH. Put all the action on the RELEASE. If the button is just tapped, it's indistinguishable from a PUSH; it happens too fast. You can set a flag in the HOLD that will prevent the RELEASE event if the HOLD is executed. The RELEASE will only take action if the HOLD did not. If you don't trap it like this, both will happen; likewise, if you put something on the PUSH, it will also happen every time.

Dave
I believe this is what I wrote earlier but, you get the option of two different commands based upon the time you hold the button. If use a timeline you can get as many different commands as you want based upon how long you hold the button,.

vining

Looks like Dave's makes the most sense. The hold doesn't require the release to execute, doesn't use waits and uses very little code. It's so simple it's stupid.

NMarkRoberts

vining wrote:

The hold doesn't require the release to execute, doesn't use waits and uses very little code. It's so simple it's stupid.

But that subverts the original purpose and common usage of a hold, which is for a repeating action eg volume ramping or camera panning.

Consequently you have to write extra code to prevent a repeat at 10,15 seconds and you leave a legacy of potential confusion for the next programmer.

Using the release to trigger the logic looks interesting but what if the release happens at 10 seconds? The action was meant to occur at 5 seconds.

A cancel_wait / wait on the push is the correct way to do this. It's bulletproof and it's obvious and it doesn't entirely rely upon the release.

Uncompiled and untested:

push:
  {
  bWaiting = True
  cancel_wait 'MyWait'
  wait 50 'MyWait'
    {
    bWaiting = False
    DoIt()
    }
  {
release:
  {
  bWaiting = False
  cancel_wait 'MyWait'
  }

DHawthorne

My example wasn't meant for a HOLD with any kind of repeating, just separate actions for a hold and a tap. I use it all the time for things like an "All Off" on a multi zone system, where a tap just turns off the local zone, and a hold turns off the house; or radio presets where a tap goes to the preset, and hold stores a new preset (which is exactly what the OP posted about).

For volume ramping, and that kind of thing, I often just use HOLD [<time>, REPEAT]. In that case, I wouldn't use the release, but have identical operations in the PUSH and the HOLD ... a tap would do it once, and then it would start repeating when held. But that is for the same action on both. I don't see any compelling reason to use a wait or timeline when they have it build right into button events already. It works perfectly for serial control devices with volume control, and you can adjust the <time> value for whatever pace works the most smoothly with your device.

However, I would emphatically not say that any particular technique is "right" and others "wrong," if they both do the job. I'm just offering alternatives.

vining

NMarkRoberts wrote:

But that subverts the original purpose and common usage of a hold, which is for a repeating action eg volume ramping or camera panning.

I don't know about original purpose but definitely common usage. Most devices wouldn't have a need to do both. Typically you would either have a hold w/ the repeat function or just a plain hold and a fixed hold time but if you wanted to do both you could.

I have no idea what purpose originated this thread but I would think a Tuner or XM presets would be a good example. Push the button and go to the preset station. Hold for 5 seconds store currently playing station as the selected preset value.

Joe Hebert

vining wrote:

Looks like Dave's makes the most sense?It's so simple it's stupid.

NMarkRoberts wrote:

But that subverts the original purpose and common usage of a hold

But it doesn?t subvert the original question posted at the top of the thread. I also think it?s an elegant (I mean so simple it?s stupid) solution. Then again, it doesn?t really matter what I think.

DHawthorne wrote:

I would emphatically not say that any particular technique is "right" and others "wrong," if they both do the job.

Amen to that. Different is what makes the world go around.