Windows Main Form slows down processing if I do not click on it

chwaitang

Member
Joined
Apr 4, 2021
Messages
8
Programming Experience
5-10
Hi All.

I have encountered a weird problem as follows:
I am running C# Win Form app build with Visual Studio Community 2019.

The main form will be constantly receiving CAN messages via USB-CAN adaptor using DLL file provided by CAN manufacturer.
I clicked a button to select which particular CAN-ID message I want to process and display. Then a separate sub form opens up
and decodes the parameters in CAN message and then plots in a line chart the received and decoded variables.

This chart plotting in sub form slows down. I found out this happens when I DO NOT CLICK and HOLD on the main form window continuously.
When I do click and hold on the main form window, I can see CAN-ID message count with its timestamps and also raw hex data of CAN packet is
shown on a display log in the main form and is updating and running continuous.

When I let go and do not click on the main form window, the update in main form display log slows down and is only updated once every 20 - 30 plus seconds.
But I can see that the message count is correct as there is some difference between CAN message count between each update shown in display log. This means
the CAN message is still being received in between consecutive updates shown in display log window ion main form.

But in the above case, the chart plot in sub form slows down and there are many missing data points not plotted as sub form is not receiving those data points in between updates.
The timestamp of each data point send to sub form from the main is shown on sub form and it also freezes between updates. But when I click on main form window, both the
display log window in the main and received data interval time stamps in the sub form are running smoothly and continuously.

I have tried what means I know and also googled on this problem with no result.
Please advise.

Best regards
Tang
 
Oh! I see what you are trying to say. The BeginInvoke() ends up creating the timer in the UI thread anyway.
 
I would suggest that things are in such a mess now that the best option is to go back to the drawing board and start again. Start by not writing any code at all. Do some planning before you write your code so you know what it has to do before you write it. Think about the steps involved and the order they need to be performed in. You can mark tasks as being UI-bound or not at that stage. You will then have a clear idea of what gets executed on which thread and WHY. That way, you won't end up doing silly things like calling Invoke from code that obviously gets executed on the main thread. Basically, you've got yourself into a tangle and it will be easier to start again and do it properly from the outset than to untangle what you have. You can ask questions along the way to do it right, rather than asking us to clean up the mess at the end.
 
I have try separate the ui thread processing from data thread processing. The display log in main window updates now but still slower compared with same program running on other laptops which show fast and smooth update on display log. It may be that particular laptop has OS/program priority issue? The same program running on that particular laptop always show delay in processing (sending out same periodic CAN messages) compared with the others (I am using Windows Form Timer) - meaning if i want to send CAN message evrery 10msec, it takes 20msec interval between adjacent transmitted CAN messages but that is ok cos I received every 20msec on the receiver side. But when i used other laptops, the time interval between adjacent transmitted CAN messages is close to 10msec on average. Right now, all seems ok when running on other laptops, no slow display log update and little to no lag when running on other laptops.
 
Any chance that laptop has the CPU running throttled all the time?
 

Latest posts

Back
Top Bottom