Right-clicking titlebar halts Ethernet

[apbenedetti]

I have an application that is receiving a stream of 19B messages over Ethernet at 12.8kHz. Within the 19B, I have a counter used to check integrity of the message ensuring I do not miss any messages. The stream works, and my application can process the information, but it is not robust. If any titlebar (from within my running application) is right-clicked, it causes the Ethernet traffic to stop for the duration of the click; ie. holding the right-button, the LEDs on my switch go solid instead of blinking. Because of the higher frequency, several messages are not received by my computer and the integrity counter is off, which sends a 'kill stream' message to the other device. There were occassional issues with moving the panels around, but I've turned off ATTR_MOVABLE and ATTR_CAN_MINIMIZE  with SetPanelAttribute() for the panel that initiates the stream, and I hide all other panels, thus the only interactions that can be done to panel is click a command button to send a 'kill stream' message, or X (close) the panel, which also sends a 'kill stream' message.

I was hoping there was a simple SetPanelAttribute() call to remove the right-click pop-up menu from the titlebar, but I didn't see anything. I wonder if it's even possible because it seems to be Windows functionality.

After some searching, I wonder if using SetPriorityClass from WinBase.h is what I want to deal with, but I am not familiar with Win32 API stuff nor know much about threads, etc. If there's an easier method, I would very much be open to it.

I appreciate any insight, and can provide more information if required.

The application has been developed using v10.0.0.

[apbenedetti · Accepted solution]

Embarrassing... There's a SetPanelAttribute() that takes care of this problem; ATTR_TITLEBAR_VISIBLE.

Can't believe I overlooked that.

[Wolfgang · Accepted solution]

Are you using a timer? Then see here. In this case changing the priority class will not help, you would need two different threads (async timer callbacks execute in their own thread)

[apbenedetti]

I do have a synchronous timer calling ClientTCPRead(). That certainly looks to be the culprit.

I, however, am satisfied with my lazy work around solution for the time being; have to meet a deadline.