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;}

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

There are a whole bunch of threads here about about trying to add things like your own long press.  I on the f5/f5+, long press of the upper right button is a configurable hot key, long press of the lower button is another user configurable hot key, long press of down defaults to the music player of the f5+, etc.  And long press of up is "menu" (which you'll see in onMenu().