Developers of Plug-Ins:
If you are not familiar with the terms Early Binding and Late Binding, let me try to give a layman's description: Early binding involves the compiler having the prototypes (descriptions) of all of the procedures you are using in HomeSeer sort of "hard coded". It looks at the reference to HomeSeer's scheduler and saves the prototypes as well as the version, and that avoids the alternative (late binding) which can be slower. Late binding is where you are referencing an object (in this case the HomeSeer Scheduler) as an object, and when your code makes a call into HomeSeer, it finds the prototype of the procedure you are calling for purposes of passing parameters at the time the call is made.
We have always warned developers not to use early binding, but have not officially documented it in the SDK or posted it here, so that is why I am posting this now.
If you use early binding because in your development environment it shows you the prototype for the procedure you are calling (and all of the properties you are referencing) then that is fine, but you must convert it to late binding before you compile it for distribution to users.
If you do not do this and you leave your plug-in using early binding, then what happens is that when we make a change to HomeSeer, your plug-in instantly breaks. Case in point: I just made a change that adds a 3rd optional parameter to WriteLog (hs.WriteLog) which is a very popular procedure... A plug-in that I had active on my development system because I was testing its installer suddenly burped, because even though the new 3rd parameter was optional, the prototype had changed so it did not find the version of HomeSeer's scheduler that it expected.
So please remember to use late binding in your final product being shipped to users!
If you are not familiar with the terms Early Binding and Late Binding, let me try to give a layman's description: Early binding involves the compiler having the prototypes (descriptions) of all of the procedures you are using in HomeSeer sort of "hard coded". It looks at the reference to HomeSeer's scheduler and saves the prototypes as well as the version, and that avoids the alternative (late binding) which can be slower. Late binding is where you are referencing an object (in this case the HomeSeer Scheduler) as an object, and when your code makes a call into HomeSeer, it finds the prototype of the procedure you are calling for purposes of passing parameters at the time the call is made.
We have always warned developers not to use early binding, but have not officially documented it in the SDK or posted it here, so that is why I am posting this now.
If you use early binding because in your development environment it shows you the prototype for the procedure you are calling (and all of the properties you are referencing) then that is fine, but you must convert it to late binding before you compile it for distribution to users.
If you do not do this and you leave your plug-in using early binding, then what happens is that when we make a change to HomeSeer, your plug-in instantly breaks. Case in point: I just made a change that adds a 3rd optional parameter to WriteLog (hs.WriteLog) which is a very popular procedure... A plug-in that I had active on my development system because I was testing its installer suddenly burped, because even though the new 3rd parameter was optional, the prototype had changed so it did not find the version of HomeSeer's scheduler that it expected.
So please remember to use late binding in your final product being shipped to users!
Comment