A History of the Development of the STK Object Model
- May 5, 2017
- Tech Tip
-
Integration
Gather around class. In this lesson, we are going to discuss the history of the development of the STK Object Model starting from STK 5 and moving to STK 11.
The STK Object Model (OM) follows the logic of the STK desktop application. When AGI developers created the STK OM project, they named it STK Engine. Their idea was that future versions of the STK desktop application would be created on top of the STK Engine. That idea was never fully realized, but the result was that the object model closely follows the workflow of the user interface.
We are going to talk about the history of the customization of the Systems Tool Kit. Each time we introduced new features and capabilities we had to decide if we wanted new interfaces to follow workflow of old code or apply lessons we learned from using the Object Model. In most cases, we choose to remain consistent with exception of the brand new modules in the STK like the Astrogator, Analysis Workbench, and Aviator
Originally, the only way to programmatically modify STK was through “Connect Commands”. The outside applications were able to establish TCP/IP connection with STK and exchange string commands. While STK OM was created as replacement for the Connect commands, the Connect commands can still be used as part of the STK OM. The Connect commands are still important as they fill current gaps in the STK OM.
STK 10 featured brand new visualization. The visualization code was originally developed for our Components product and integrated into STK 10. Before STK 10, the only way to interact with 2D and 3D windows was through Connect commands. New visualization code included the very powerful graphic primitives library. The library allows developers to draw objects on globe space and screen space, as well as, manipulate the camera object. However, due its complexity, it is not possible to save graphics primitives with the scenario.
Thanks for reading and class dismissed.
The STK Object Model (OM) follows the logic of the STK desktop application. When AGI developers created the STK OM project, they named it STK Engine. Their idea was that future versions of the STK desktop application would be created on top of the STK Engine. That idea was never fully realized, but the result was that the object model closely follows the workflow of the user interface.
We are going to talk about the history of the customization of the Systems Tool Kit. Each time we introduced new features and capabilities we had to decide if we wanted new interfaces to follow workflow of old code or apply lessons we learned from using the Object Model. In most cases, we choose to remain consistent with exception of the brand new modules in the STK like the Astrogator, Analysis Workbench, and Aviator
Originally, the only way to programmatically modify STK was through “Connect Commands”. The outside applications were able to establish TCP/IP connection with STK and exchange string commands. While STK OM was created as replacement for the Connect commands, the Connect commands can still be used as part of the STK OM. The Connect commands are still important as they fill current gaps in the STK OM.
STK 5
STK 5 was the first Windows OS only version of the STK. One of the new features was an HTML browser control. The purpose of the control was to allow the users to create custom user interfaces and communicate with STK through the Connect commands. Some of the first work on the STK Object Model was done at this time. The pattern of getting the application object and the STK root object was established at this time. The pointer to STK application was accessed through the "Personality" property of the AGI Application object. More on this later.STK 7
STK 7 introduced the STK Object Model. The only application types available at time were stand-alone applications. At the same time, STK OM automated only a portion of the functionality available in STK Desktop application focusing on the primary objects in the STK. This required high reliance on the Connect commands to fill the gaps. Since the Personality property was already used by HTML pages, we created the Personality2 property.STK 8 and STK 9
STK 8 expanded code coverage to analysis objects and group objects (chains and constellations). STK 9 presented a major expansion of the STK Object Model. We added the ability to control STK from outside applications, as well as, from inside STK in form of UI Plugins. STK 9 also included the Astrogator propagator and Vector Geometry Tool (VGT).STK 10
STK 10 saw the creation of the Analysis Workbench. The Analysis Workbench consisted of new modules like the Time Tool and Calculation Tool, as well as the existing Vector Geometry Tool. Since we already had the VGT interface as part of the IAgStkObject, we had three choices: replace VGT interface with new Analysis Workbench interface, add Time Tool and Calculation Tool as independent interfaces to the IAgStkObject, or add all Analysis Workbench functionality to the VGT interface. We choose the third option. Our desire to maintain backwards compability overwrote the need to present logical property names.STK 10 featured brand new visualization. The visualization code was originally developed for our Components product and integrated into STK 10. Before STK 10, the only way to interact with 2D and 3D windows was through Connect commands. New visualization code included the very powerful graphic primitives library. The library allows developers to draw objects on globe space and screen space, as well as, manipulate the camera object. However, due its complexity, it is not possible to save graphics primitives with the scenario.
STK 11
STK 11 added support for secondary objects like Transmitters, Radars, etc., and a beta version of the Aviator object model.Thanks for reading and class dismissed.