Announcement

Collapse
No announcement yet.

PED named key does not honor case when retried from Feature object

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • alexbk66
    replied
    Originally posted by kriz83 View Post
    We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.
    We could have a discussion, but probably not in this thread. But quickly about exceptions - sometimes exceptions are normal, often in communication apps (i.e. TCP/IP) or database apps... And often you can't let app just crash - i.e. in real time control apps or multi-user apps. I work on CSIRO on many projects for Australian Synchrotron or solar thermal power stations.

    Leave a comment:


  • kriz83
    replied
    Originally posted by racerfern View Post
    I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.
    Personally (and in our entire organisation), we prefer functions that have 1 or 2 return paths. If you have a multitude of conditions to check, than probably the function could/should be splitted up.

    We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.

    Leave a comment:


  • alexbk66
    replied
    Originally posted by racerfern View Post
    I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.
    No problem The reason been - we just had similar discussion at work....

    Leave a comment:


  • racerfern
    replied
    I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.

    Leave a comment:


  • alexbk66
    replied
    Originally posted by kriz83 View Post
    I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

    Otherwise:
    Code:
    if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )
    Avoiding exceptions is always a good taste.
    And if you have many checks - can you imagine how long the line would be? And debugging this will be a nightmare - how do you find which check fails?
    Sorry for drugging this off-topic...
    [EDIT] But what I don't get - why there's two try/catch blocks?

    Leave a comment:


  • kriz83
    replied
    I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

    Otherwise:
    Code:
    if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )
    The point I was trying to make here is that the cyclomatic complexity of this little function is quite high, but that is irrelevant to the context of this issue :-)

    Leave a comment:


  • alexbk66
    replied
    One note -
    Code:
    If String.IsNullOrEmpty(Key.Trim)
    - will fail if Key is null. Should be

    Code:
    If String.IsNullOrEmpty(Key?.Trim)

    Leave a comment:


  • alexbk66
    replied
    Originally posted by kriz83 View Post
    Never seen a function with that many different return paths.
    I actually prefer the style above - if any condition not satisfied - return False. Then do the stuff and return True. Any exception - return False.

    Do you believe this looks better?

    Click image for larger version

Name:	returnpaths.jpg
Views:	51
Size:	44.6 KB
ID:	1384773

    Leave a comment:


  • kriz83
    replied
    Reviving a 5 month old thread? Just fix the issue plz ...

    Never seen a function with that many different return paths. This is an absolute drama when debugging an application.

    Verstuurd vanaf mijn SM-G965F met Tapatalk




    Leave a comment:


  • JLDubz
    replied
    Can confirm that the HS3 SDK did not support mixed case keys. You can find the source code attached:

    Code:
            Public Function AddNamed(ByVal Key As String, ByVal Obj As Object) As Boolean
                Try
                    If Key Is Nothing Then Return False
                    If String.IsNullOrEmpty(Key.Trim) Then Return False
                    If Obj Is Nothing Then Return False
                    CheckNamed()
                    SyncLock Ncol.SyncRoot
                        Try
                            If Ncol.ContainsKey(Key.Trim.ToLower) Then Return False
                            SyncLock Ncol.SyncRoot
                                Ncol.Add(Key.Trim.ToLower, Obj)
                            End SyncLock
                            Return True
                        Catch ex As Exception
                            Return False
                        End Try
                    End SyncLock
                Catch ex As Exception
                    Return False
                End Try
            End Function
    
            Public Function AddUnNamed(ByVal Obj As Object) As Integer
                Try
                    If Obj Is Nothing Then Return -1
                    CheckUnNamed()
                    SyncLock UNcol.SyncRoot
                        Return UNcol.Add(Obj)
                    End SyncLock
                Catch ex As Exception
                    Return -1
                End Try
            End Function
    You can see it in this line here: Ncol.Add(Key.Trim.ToLower, Obj)

    Will look into ditching this limitation though. I'm updating the documentation to reflect this until we can implement a workaround.

    Leave a comment:


  • rmasonjr
    replied
    HS3 definitely allowed mixed case PED keys.

    Leave a comment:


  • Michael McSharry
    replied
    I am porting a HS3 implementation so I do not think it was the case with HS3.

    Leave a comment:


  • alexbk66
    replied
    I think it was always the case, even in HS3

    Leave a comment:


  • rmasonjr
    replied
    I switched all my PED to lowercase based on this post. rjh didnt comment, so I assume that is the way it's going to be going forward.

    Leave a comment:


  • PED named key does not honor case when retried from Feature object

    A PED entry was made with:

    Code:
    Const PEDKEY As String = "PEDkey"
    PED.AddNamed(PEDKEY, Join(arrPED, ","))
    When observed with Debugger the PED object was as expected named entry with key ""PEDkey"

    The feature was updated to contain the PED with:

    Code:
    hs.UpdatePropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData, PED)
    Subsequently a new PED object was retrieved from the Feature:

    Code:
    Dim PED As HomeSeer.PluginSdk.Devices.PlugExtraData = hs.GetPropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData)
    The following confirms that the key was stored as lower case text so PED could not be retrieved using the named key unless converted to lower case

    Code:
    ?PED.NamedKeys
    Count = 1
        (0): "pedkey"
    
    ?PED.ContainsNamed(PEDKEY) 
    False
    
    ?PED.ContainsNamed("pedkey") 
    True
Working...
X