Hello @simonkerscher i saw your pull request and tried to reproduce it. But unfortunatelly i did not saw a real bug with the current develop branch. Can you explain what is your fault?

The line cansend vcan0 123#0 does not work in my terminal as the data bytes are not complete. I can either use cansend vcan0 123#00 or cansend vcan0 123# while running python3 -m can.viewer -i socketcan -c vcan0 in an other terminal and the output seems correct

Hi @pkess . Apologies for the unclear instructions. I have amended my commit message and quoted code blocks to make sure commands don't get edited by Github directly.

Thes bug could easily be replicated by running:
python can_viewer.py -c vcan0 -i socketcan -d "123:>BB"
In another terminal send:
cansend vcan0 123#FFFF
Followed by:
cansend vcan0 123#0001

Currently, the output is:
2 0.976789 0.976789 0x123 2 00 01 0 1 255
while I would expect:
2 1.509172 1.509172 0x123 2 00 01 0 1

Ok, now i was able to reproduce this. But wouldn't it be easier to always write spaces until end of line than remember the old line length? Maybe @hardbyte or @felixdivo can add some comment here

Codecov Report

Merging #1201 (f610f54) into develop (e7a2b04) will increase coverage by 0.23%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1201      +/-   ##
===========================================
+ Coverage    65.65%   65.89%   +0.23%     
===========================================
  Files           86       86              
  Lines         8846     8875      +29     
===========================================
+ Hits          5808     5848      +40     
+ Misses        3038     3027      -11     

Ok, now i was able to reproduce this. But wouldn't it be easier to always write spaces until end of line than remember the old line length? Maybe @hardbyte or @felixdivo can add some comment here

As this is the last field, I guess we could write spaces until the end of the line. I was trying to follow the approach used for a shortened message in lines 210-217, only overwriting spaces that had changed.

                # Clear the old data bytes when the length of the new message is shorter
                if msg.dlc < self.ids[key]["msg"].dlc:
                    self.draw_line(
                        self.ids[key]["row"],
                        # Start drawing at the last byte that is not in the new message
                        52 + msg.dlc * 3,
                        # Draw spaces where the old bytes were drawn
                        " " * ((self.ids[key]["msg"].dlc - msg.dlc) * 3 - 1),
                    )

Thes bug could easily be replicated by running: python can_viewer.py -c vcan0 -i socketcan -d "123:>BB" In another terminal send: cansend vcan0 123#FFFF Followed by: cansend vcan0 123#0001

Currently, the output is: 2 0.976789 0.976789 0x123 2 00 01 0 1 255 while I would expect: 2 1.509172 1.509172 0x123 2 00 01 0 1

I think you are looking in the wrong place. Why is there a 255 in your output? It should be hexadecimal FF, right?

Thes bug could easily be replicated by running: python can_viewer.py -c vcan0 -i socketcan -d "123:>BB" In another terminal send: cansend vcan0 123#FFFF Followed by: cansend vcan0 123#0001
Currently, the output is: 2 0.976789 0.976789 0x123 2 00 01 0 1 255 while I would expect: 2 1.509172 1.509172 0x123 2 00 01 0 1

I think you are looking in the wrong place. Why is there a 255 in your output? It should be hexadecimal FF, right?

No, the 255 is from decoding the previous value, e.g.

0x123 2 FF FF 255 255
|     | |  |  |   decoded second byte
|     | |  |  decoded first byte
|     | |  second byte
|     | first byte
     message length
node ID

Sending both messages in order, we get

...0x123 2 FF FF 255 255 # Decoding 123#FFFF
...0x123 2 00 01 0 1     # Correctly decoding 123#0001
...0x123 2 00 01 0 1 255 # Overwriting line 1 with line 2, without overwriting trailing characters. This is the current wrong behaviour.

@zariiii9003 Can we merge this?