Update ExtensionsAndHelpers.cs to fix cycleTime problem

[Starkxim]

When the cycletime is defined as a FLOAT type, the original code will not be able to read the cycletime and will report an error, I added a little bit of judgment to make it able to read the FLOAT type cycletime

[Adhara3]

Hi,

I fear we ended up in the usual lack of spec issue.
If 20.000 is a valid value, why would 20.500 not be? I mean, the cast solution is fine but will not give you the right number.
So the question is: are we sure the GenMsgCycleTime should be an integer value?

Bottom line: I will merge the PR to unlock you but technically/philosophically speaking this may lead to other issues.

Regards
A

[Starkxim]

Hi @Adhara3,

Thank you for raising this concern! I did some testing in Vector's CANdb++ Editor to verify the behavior.

Here's what I found:

Even when the GenMsgCycleTime property is defined as a float type in the DBC file, and I set a message's cycle time to a float value like 10.5 or 10.9, the CANdb++ Editor's Definition interface displays it as an integer by truncating the decimal part (i.e., 10.5 → 10, 10.9 → 10).

More importantly, CANoe only supports integer transmission cycles. A cycle time like 10.8ms is invalid/illegal in CANoe. This means that in real-world CAN bus applications, cycle times must always be integers.

This behavior suggests that:

1. The DBC format allows GenMsgCycleTime to be stored as a float type for some reason (perhaps for compatibility or flexibility)
2. However, in practice, the cycle time is treated as an integer value, with the decimal portion being discarded

Based on this observation, I believe the current PR implementation using (int)property.FloatCustomProperty.Value (which truncates the decimal) aligns with how CANdb++ Editor handles this property.

That said, if you prefer a more explicit rounding approach like (int)Math.Round(property. FloatCustomProperty.Value), I'm happy to update the code. Please let me know your preference!

Best regards

[Adhara3]

Hi,

In an ideal world if the property is integer then it should be specified as such, given the spec is clear and distinguish between integer and floating point values. Usually what happens is that the parsing should fail in strict mode, work in loose mode.
This to enforce correctly formatted files.

DBC is instead a pile of sh*t where tons of wrongly formatted files are around so basically we must work in loose mode all the time, so the current implementation is fine.
It's a bit of a pity because that makes parsing much more complex if one can specify values in any available format.
And again in an ideal world, if one specifies 10.2 then the parsing should fail instead of rounding because the provided value is invalid. A parsing should parse and validate, not decide how to get a suitable value. Nobody wants to see failures, people prefer to see all green even if the value is not what was specified in the file. At least a warning should be raise or, as a user, I would like to know that the dbc contains an invalid value that has been somehow fixed.

I'm a bit a black swan,.

Bottom line: the changed is merged, let's keep it like that.
A