On 24/03/2019 12:57, Bob wrote:

Bill, it is not an insurmountable problem, it is a distraction to have the task bar appear unexpectedly, and not go away unless the WSJT window is brought to the foreground.  Other than the distraction, the taskbar covers the lower part of windows at the bottom of the screen. SeventyThree(s).

Hi Bob,

understood, but if you are sending a Reply UDP message to WSJT-X from another application then you are starting a QSO and the WSJT-X windows should be given focus. I agree the two check boxes "Notify on accepted UDP request" and "Accepted UDP request restores window" should have a bearing on this behaviour. I will see if I can reproduce the issue and investigate.

73
Bill
G4WJS.

Gentlemen,

I'm glad to have found this thread! I have been trying to figure out what these two options do. And why I might use them. This is the only thread I've found that discusses them, and the documentation doesn't mention them either. This thread however helped me understand they are or may be related to an issue I've been having. Same as what Bob mentioned, having the taskbar raised covers the bottom of the screen and obscures a portion of other windows. I have 5 displays, so this happens to a great many program windows. 

When I double click a CQ callsign cell in JTalert, it loads up the std message and enables transmit in WSJT-X. I have auto sequence enabled, so generally the only direct interaction I have with WSJT-X is to confirm the logging action. There is no need to select the WSJT-X application otherwise, other than to cause the taskbar to go away.

I'd be forever grateful to stop this taskbar behavior. It's very frustrating and seemingly unnecessary. From Bill's comment above, that these options 'should' have an impact on the behavior, I have to guess that this behavior is not their primary function. What do they primarily do, and how would I decide to check them or not? Bill, did you have opportunity to followup and investigate?

THANK YOU so much for all you do, we benefit tremendously!