IComComponent new member

[TheColonel26]

I would like to convert all my code over to using IComComponent instead of the concrete driver classes. This is just for future flexibility. My problem is that, I then do not have access to the IP Address which I would like to have for error messages, and logging.

Would you be willing to added a new member to IComComponent somthing like string AddressOrPort { get; } which would either be populated with a IP address or a serial port name.

If not is there any other way I can access it?

[Archie]

It is not possible to add IPAddress to IComponent because not all drivers use an IPAddress, such as the serial port drivers. The IComComponent is the interface that defines how controls interact with the drivers. The controls do not need to be aware of the IPAddress otherwise the controls would then be limited only to Ethernet drivers.

If the property name were changed to AddressOf, then it would likely generate a lot of confusion.

[Archie]

If you wish to create your own version of the Interface, this is the current:

Code: [Select]

Public Interface IComComponent
    Function Subscribe(ByVal plcAddress As String, ByVal numberOfElements As Int16, ByVal pollRate As Integer, ByVal callback As EventHandler(Of Common.PlcComEventArgs)) As Integer
    Function Unsubscribe(ByVal id As Integer) As Integer
    Function BeginRead(ByVal startAddress As String, ByVal numberOfElements As Integer) As Integer
    Function Read(ByVal startAddress As String, ByVal numberOfElements As Integer) As String()
    Function BeginWrite(ByVal startAddress As String, ByVal numberOfElements As Integer, ByVal dataToWrite() As String) As Integer
    Function Write(ByVal startAddress As String, ByVal dataToWrite As String) As Integer ' String
    Property DisableSubscriptions() As Boolean
End Interface


[TheColonel26]

I think you are misunderstand me. I am asking for a read only string if it is Ethernet it returns the IP address, if it a Serial Port it returns the port name;

I have done this before for an interface that represents a hipot tester, the hardware can be connected to with either Ethernet or Serial.

Yes I have already looked at the interface definition. I considered extending it but I would rather not because I would also have to alter all of the drivers classes which would prevent me from receiving updates unless I kept changing the code each time.

[Archie]

My philosophy.... Any step toward generic naming is a step away from specific naming, which in turn would result in less intuitive. When a new user adds an Ethernet driver the first thing they will look for is IPAddress setting. If they cannot find it, then the next move is to abandon the software or spend time looking for assistance.

So the consideration in renaming something critical like the IPAddress and PortName address has to be looked at it as that it may benefit 1 in 10,000 users, but will confuse 3,000 out of those 10,000. I would guess that over 90% of the users would not be aware of what an interface is or how to use it simply because it is not necessary to create HMI applications.

I'm not trying to sound negative or resistant to a change, but I must always keep in consideration what will be the most beneficial to the majority. One of the top objectives is to continue to increase the user base size and the way this is to be done is by keeping the basics very easy and intuitive.

If the target users were all seasoned .NET developers, then I would be all for your suggestion.

[TheColonel26]

I wasn't suggesting renaming the IPAddress and PortName properties on the concrete classes. Just that they would have a get only property Call IPAddressPortName

C# pseudo code would be something like this on the concrete classes
Ethernet would be like this

Code: [Select]

public string IPAddressPortName {get { return _IPaddress; }}Serial would be something like this

Code: [Select]

public string IPAddressPortName {get { return _portname; }}
Having said that I can now see how that might getting confusing because the concrete classes would have 2 properties, one that is settable and one that is not, they would have different names, but still that could be confusing.

It just occurred to me that I am being dumb, I can just inherit from the the driver classes, implement the new property, and then create a inherited interface and have the new children implement that. Maintenance work should be minimal that way.