Menu2 title string placement too high on Vivoactive 3?

Just a little update: One of my Vivoactive 3 users was kind enough to provide me a video of my app running on the actual device and it appears to work fine (e.g. the title string isn't cut off and looks similar to the Fenix 5). 

There seem to be a few discrepancies between the simulator and the real device, as the single button on the right side also didn't behave like in the simulator (pressing it on the real device returned the user to the watch face, not ideal if pressing it should be the single point of interaction with your widget). I've implemented touch controls to circumvent the strange behavior of the button and the title appearance seems to be a simulator problem that is not affecting the real thing. 

Sounds like you might have an issue in your input delegate.  Returning to the WF can be the result of not having a return statement in something like onKey() or onSelect().  The va3 is really picky about that.

Thanks for the answer, Jim!

I extend BehaviorDelegate and don't overwrite onKey() as I'm working with the long press solution posted by Travis, I think? 

function onKeyPressed(evt) {
	var key = evt.getKey();
	
	if (keys[key] == null) {
		keys[key] = new KeyHeldDelegate(me, key);
	}
	
	timer.stop();
	timer.start(keys[key].method(:invoke), resource_manager.longpress_threshold, false);
	
	return true; 
}

function onKeyReleased(evt) {
	var key = evt.getKey();
	
	if (keys[key] == null) {
		return true;
	}
	
	keys[key] = null;
	
	timer.stop();
	
	fast_manager.nextPage();
	
	return true;
}

If I read the API docs correctly, returning true should tell the watch, that I want to handle this key event.  Should I overwrite onKey() and onSelect() anyways just to make sure they don't conflict with me trying to handle long presses? E.g.:

function onKey(evt) { return true;}
function onSelect(evt) { return true;}

Trying to detect your own long presses isn't a great thing to do, as what buttons do what really vary by device, including differences with hot keys and things like onboard music.

What are you trying to accomplish?  With a widget, in the main view you are limited to what you can do - things like prev/next aren't available, but if you push a second view, they are.

The alternative of having the user guess, if held the button long enough to count as a long press or not, because the action only happens after he lets go of the button is not ideal, so I figured that would be the best solution for the scenario. 

Here's a quick video showing the user interactions on my simulator. https://streamable.com/ta70ef

Basically I use long presses (with a user configurable delay) to open menus for setting goals or ending / cancelling fasts and regular presses to advance the view to the next page (the widget only has one view that is simply redrawn with the data of the next page, excluding the Menu2 views I'm pushing on long presses).

Gotcha. Thanks for the detailed answers and your time, Jim! 

It looks like I will need to rewrite portions of the widget so it doesn't interfere with firmware functions. 

The way I programmed it I was under the impression, that my widget would have full control over the enter key as long as it is running, which works fine on my Fenix 5 and a friend's D2 Charlie. I never thought about interference with hot keys or other shortcuts to be honest. 

Thank you for the heads up and I guess I better grab some coffee, because it's gonna be a long night