I have talked to our developers regarding this.
If you have a smaller symbol (4bytes) and use the ValueEdit to relay all 4 Bytes you'll notice that this does
not occur, what you're seeing the ValueEdit being pushed beyond its value range.
This behaviour is more or less precisely the reason the "raw"-data format in Symbol files do exist,
as they is no conversion from panel to signal the value can simply be parsed.
Like mentioned before, when using a symbol file you can simply use the RAW format and pass
the values without any denotation of hex.
Is there a particular reason you use the dbc format or can you switch to symbol files exclusively?
The DBC is being used as this is one among many signals in our project that are displayed on the GUI panel and I would like to add this CAN signal to the GUI and to the DBC.
Since we already have a DBC and many signals mapped on the panel, my intention was to add one more to the list. This is probably the only signal in the dbc that is 8byte long and hence there is a possibility that we may want to write large values.
As you mentioned, the value edit works perfectly for low values. Your suggestion is to remove this signal from the dbc and handle it with symbol file?
Well, if using Symbol-files is not a
disadvantage to you that would be my proposal, yes.
Otherwise, one would have to come up with a workround
as the DBC doesnt handle raw-types and the ValueEdit cannot
convert the Values given to it due to its range