CAN.Message.Data readonly

Archive
1

Is there any reason for this field to be readonly?

I would lik to simply affect Data with a byte array like this:

mess[0] = new GHI.Premium.Hardware.CAN.Message();
mess[0].ArbID = CANHS.candttx;
mess[0].DLC = 8;
mess[0].IsEID = true;
mess[0].IsRTR = false;
mess[0].Data = BitConverter.GetBytes((long)1);

but unfortunately a readonlyfield can not be assigned (while mess[0].Data[0] can be)

2

I think it is done this way to enforce size limit of the array.

3

This may be the reason… but an unconvevenient reason… Do you think it can have an impact on efficiency?

4

I agree. Personally, I would have done it differently. But there is no standard in writing APIs, so everybody does things differently. The main issue is once the API is out, it is really “hard” to change the API. All the documentation becomes invalid, examples don’t work, user code breaks. It has been done here few times. As for the efficiency, probably not a very big deal.

5

There actually IS a de facto standard for .NET :wink:

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613

I guess CAN implementation is one of the oldest in GHI bag. It has many flaws…

6

@ Simon from Vilnius - I have that book :wink:

7

I have a list of changes to CAN on my end and will add this to it as well.

8

Oooooh, there’s a CAN To-Do list? I have a couple suggestions too!

9

Please provide any suggestions you have.

10

Opened a new topic:

https://www.ghielectronics.com/community/forum/topic?id=13624

11

thanks

12

Nice drop Simon. I also agree with all your points.