Enhancement - ignore head unit buttons when GUI is minimized or out of focus

[BrRoBo]

I've accidentally killed my ride in Zwift a couple times by hitting the Cancel button on the head unit. Well, didn't "kill" the Zwift ride, but does exit the FortiusAnt's active mode (exits "Start" mode) which effectively ends sending Ant data and hence stops the ride.

Why not ignore the buttons when the GUI is minimized or when out of focus?

[WouterJD]

If you run FortiusANT, hidden behind Zwift and want to control with the head unit on top of your bike that would not be possible.
I would say: it happens once but not again...

[BrRoBo]

I am not looking to use the head unit in Zwift.

My thoughts are that the FortiusAnt GUI itself should not act like it is in front (has focus). It did kind of surprise me that I accidentally exited the "Start" mode and so interrupted my session. Is there some reason to keep the GUI responding to the head unit buttons when it is out of focus?

Usually application focus state should be checked before responding to mouse actions, otherwise every application you have open would think your mouse actions were intended for it and you would have every application taking action. I figure the same should be true with the head unit - when the GUI is out of focus it should not do anything with button events. Just thinking this would be more typical approach.

[WouterJD]

When zwifting, head unit can be used for virtual gear (up/down buttons).
So that's why head unit remains active.

[BrRoBo]

Yes, but when the GUI is in the background out of focus, why would you want it to respond to the "Cancel" button and exit the "Start" (running) mode? It is the GUI state that I am looking to stop changing. If in Zwift, only Zwift should respond to the head unit, not the GUI.

[switchabl]

I have a slightly provocative question here: do we need a button for "Stop" at all? I've only ever pressed that by accident, resulting in the same frustrating experience @BrRoBo had.

[BrRoBo]

I have a slightly provocative question here: do we need a button for "Stop" at all? I've only ever pressed that by accident, resulting in the same frustrating experience @BrRoBo had.

I do find the Stop button is useful for allow us to go back and forth between the calibrated/run mode and back to the Runoff mode. It can take a good 15 minutes of warmup riding before our trainer results stabilize (due to cold garage) and report good watts per effort.

A GUI interface should not respond to what is essentially mouse events unless that application is in focus. That is a industry standard approach to any GUI application.

[WouterJD]

requirements

• Be able to control FortiusANT from head-unit
• Ignore button when pressed inadvertently; but do attend when pressed intentionally
• Do cancel when we are in calibrate mode
• Igore it when GUI is hidden
• Do not ignore when no GUI used (console mode)

Perhaps just provoking as well.

It works as designed and I leave it the way it is.

[WouterJD]

Implemented: main window cannot be closed from the head-unit; if you do this by accident you have to get off your bike to restart the program