1 Reply Latest reply on Nov 26, 2010 7:19 PM by spilon

    PIPOINT.Data.MovingSummary

    francois_ruel

      Hi!

       

      The MovingSummary seems to be available in the PISDK but the help file show it is not implemented.

       

      I tried to use it and I'm getting an error.

       

      Set YValues = YPoint.Data.MovingSummary(StartDate, EndDate, astAverage, "1h", "10m")

       

      I'm getting an error like this object doesn't handle this action.

       

      Any used it it or know when it will be available?

       

      Thanks!

       

      Francois

        • Re: PIPOINT.Data.MovingSummary

          The PIData.MovingSummary is indeed not implemented... I know it may be confusing to see it come up in IntelliSense anyways, but there is a good reason for this:

           

          As you may already know, the PI SDK class libraries are basically COM servers; they come with .NET Interop Assemblies, but they are built on COM under the hood. In COM, unlike in .NET, you cannot change the interface definition (signature) of a class - not even adding functionality. This violates the encapsulation of the object and would break all existing clients, which basically means you cannot change COM interfaces once published.

           

          That means the PI SDK developers had to think about as much of the current and projected capability of the PI SDK, (back in the 1990's), and build PI SDK with the appropriate class and method signatures. Take a second to think about the effort involved because of this... this is quite the challenge!

           

          This is why you see a number of 'Not Implement' methods in the various PI SDK classes - some of these 'projected' methods got implemented over time, and some did not. Those methods that are not yet implemented fall in 2 categories:

          1. Those methods that don't make sense implementing anymore (e.g. because the system changed/evolved). An example of this is PIUsers.Merge.
          2. Those methods that still make sense implementing. Whether we implement those (and when) is determined by the requests we receive and their importance, considering our entire product line and available resources. This sounds scary (it actually is!), but determining this is the job of the Product Manager (PM). Of course PMs cannot just guess all of that... this is why we need you, the community, to communicate this to us: go get your requests logged in our system through Tech Support!

          Now back to the technical side of things...

           

          Another implication of the above COM rule is that any functionality you wish add should be added by means of 'secondary', or 'extended' interfaces. This means any functionality we had not envisioned in the first place, were implemented in additional interfaces - examples of this are the IEventPipe2 and IEventPipe3 interfaces, which came later to extend the functionality provided in the basic EventPipe.

           

          Hope that sheds some light on these mysterious 'Not Implemented' and 'ISomeInterface2' concepts
          You can read more on the topic in the Object Extensibility section of the "Essential COM" book from Don Box.