OverRiding OnHold native Behaviour (on a Touchscreen)

On the F3, I was told that I can overide a default Key behaviour by doing a return true, hence that's what I did to stop the app from going into the watch face screen by "returning true" to the KEY_CLOCK

I tried the same thing on a VA (works great in the sim - but in the sim, there is no watch face so can't test it)
On The VA, when i do a return true for the OnHold, apparently it will still go to the watch face.

Is there some secret to disabling or diverting the default behaviour? something besides Return True?

function onHold(evt) {
var keynum = Lang.format("$1$", [evt.getType()]);
Sys.println("onKeyPressed keynum:" + keynum);
return true;
}
  • As a long time va user, I doubt there is a way disable it's behavior, and I don't think you want to! It's a nice feature of the va that works with any app - native or CIQ. (and seems to be unique to the va)

    When you hold the screen during an activity, you don't just see the watchface (with a timeout), but also have access to the whole "native widget" loop, so during an activity, you can access stuff like "music controls" (skip this song, etc). You can also swipe and see notifications, etc, without exiting the app.

    Va users are used to this, and disabling that could be an issue for an app.

    What if.. You used "enter" for a "pause" and put up a menu with "resume/save/discard" and "lock"?.

    recording would continue with "lock", and the next "enter" would give only one option - "unlock", and during that time you ignore any other input??
  • Not entirely true. It's also applicable for the f3 and I've disabled it as it has an inherent garmin bug which I have reported where it caused the app to exit.

    It would be even better if the onkeypressed or onkeyreleased can be be worked to mimic a LONG key press. (That was what I tot these 2 functions were for, but somehow it's not behaving as expected?? Otherwise, what's the diff between onkey and onkeypressed?
  • Disabling exit to the native pages requires processing the "CLOCK_KEY" in the inputDelegate, and returning 'true'.



    https://forums.garmin.com/showthread.php?330151-LONG-Press-Down-button-and-pressing-Back-LAP-will-exit-app

    I'm not processing the KEY_CLOCK on this app. Coz, I was using onHold(). Should I then try to do onHold() and then check for KEY_CLOCK??
  • For the stuff you're doing, have you thought about getting a second hand vivoactive on Ebay or something?

    The va is a bit different than other CIQ devices, and there are things you may want to be able to test yourself.

    Not that the va does things incorrectly, but it's not a forerunner or a F3 in the way the FW does things...
  • Can't justify the price even for a 2nd hand one. the VA will cost me approx 1 months salary.
    I _think_ we all want to buy the shiny new (or even a 2nd hand one) gadget if there is enough $.

    I made some additional test using the simulator (Garmin can help us all by doing an emulator instead of a simulator, I'm sure we all agree)
    bsically just printing the keynum output and looking up the key values http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi.html
    var keynum = Lang.format("$1$", [evt.getType()]);
    Sys.println("BB :" + keynum);


    OnTap()
    returns - keynum: 0 which is Click_type_Tap

    onHold()
    returns - keynum:1 which is the Click_Type_hold

    but you're definitely right - the VA is "unique"

    There doesn't seem to be any references to KEY_CLOCK for the VA.

    Whoops.. It's calling click_type
  • Former Member
    Former Member over 9 years ago
    On the VivoActive, it is not possible to disable this behavior.

    To my knowledge, the Clock key on the Fenix was only allowed to be blocked in this way because it shares functionality with the Down key, and it was not possible to implement functionality that scrolled quickly through options by holding the Down key without blocking the Clock key.