AGI STK Engine (4DX) Blog

September 20, 2010

STK 9.2.1 is out!

Filed under: STK Object Model, VGT, Vectory Geometry API, stk — Tags: , , , — Sylvain @ 12:12 pm

STK 9.2.1 is out! You can download the new release from the ADN download center (direct link to the 9.2.1 download). The release notes are also available online here. For STK & Engine developers, the main new feature in this release is that the Vector Geometry Tool API is no longer beta and is now official!

May 18, 2009

What’s New in STK 9: User Interface Plugins

Filed under: .Net, C#, UI Plugins — Tags: , , — Peter @ 10:17 am

With the upcoming release of STK 9 we are shipping a new API called “User Interface Plugins” or “UI Plugins”. The purpose of the new API is to allow end users extend the STK User Interface in order to implement custom workflows, automate repetitive tasks, etc. Users will be able to add your custom windows, toolbars and context menus to the STK environment, and receive notifications when their custom UI elements are activated (a button on a toolbar is clicked or a menu item is selected). (more...)

May 13, 2009

STK 9 Astrogator Object Model

Filed under: .Net, C#, Java — Tags: , , , , , — Matthew @ 5:15 pm

With STK 9 just about wrapped up, I have time to talk about some of the new features added to the STK Object Model. I'll be focusing today on one of the major pieces that was added, Astrogator. For those who aren't too familiar with Astrogator, it is a specialized analysis module for interactive orbit maneuver and spacecraft trajectory design. Astrogator acts as one of the propagators available for a satellite object. This module calculates the satellite's ephemeris by executing a Mission Control Sequence, or MCS, that you define according to the requirements of your mission. By exposing it through the STK Object Model you now have more options for automating repetitive tasks, integrating with other applications or even developing your own custom application. (more...)

March 16, 2009

What’s cooking in STK Engine 9.0…

Filed under: .Net, C#, Java — Tags: , , , , — Sylvain @ 9:04 am

Hi everybody! Sorry for not posting more articles on this blog for the last couple of months. We have been busy working on STK 9.0! We have lots of exciting Engine features currently in the final stages of development (this is in addition of many, many new features in the STK Desktop application as well, both on the user interface usability and the computational capabilities). The STK 9 Seminar Series will be held tomorrow and (more...)

May 7, 2008

STK Object Model Contexts

Filed under: Uncategorized — Tags: , — Peter @ 12:22 pm

A context within the STK Object Model is an object holding the unit preferences, the Object Identify Cache (OIC) as well as access restrictions. Contexts are not directly accessible to the users, yet users can influence their behavior to a certain degree (see the following article "Root Object Isolation"). Any object created or accessible through the Object Model is associated with a context through which the object accesses the unit preferences to perform the unit conversion. The diagram below shows the two root objects sharing the same context.

STK Object Model: Root Object Isolation

In the version 8.1 we have introduced a new feature called ‘Root Object Isolation’. In a nutshell, the isolation is designed to provide a way for the 4DX developers to make multiple copies of the unit preferences. Here is a short example how to use the isolation to configure two distinct, non-overlapping unit preference sets. The code creates two independent root objects and configure each with its own set of unit preferences. This process is referred to as "isolation".

AgStkObjectRootClass rootA = new AgStkObjectRootClass();           
root.UnitPreferences.SetCurrentUnit("DistanceUnit", "km");
AgStkObjectRootClass rootB = new AgStkObjectRootClass();
// rootA and rootB  are now using non-overlapping unit preferences, i.e. the changes to the unit preferences via object “rootA” do not interfere with the unit preferences of the object “rootB”.

Note: The isolation must be done right after a new root object is instantiated. Once the root object becomes “tainted”, i.e. changed, any attempts to isolate it will not succeed and will throw an exception.

The benefits of having multiple roots isolated from each other becomes more obvious when building enterprise applications where it is necessary to make individual components as independent and isolated from each other as possible. Another example where Isolation becomes a must-have is in a type of application that is constructed out of many components, for example the Application Framework. Each add-in, to prevent interfering with other add-ins, must isolate itself from the rest of the add-ins so that each one manipulates with its own private set of unit preferences. The following diagram shows two root objects isolated from each other:

Note: the references to the STK objects are local to the context so use the “Path” property of the IAgStkObject interface to compare two instances to find whether they represent the same object within STK engine.

STK Object Model: Restricted Contexts and STK Plug-ins

Contexts are also useful for the STK engine plug-ins. A while ago, while in the process of exposing the Object Model to the Constraint Plug-ins, we realized that simply giving a full read/write access is not an option and here is why. When computing the access constraints, the engine expects its state to stay the same before and after the access computation is completed. Now imagine a custom access constraint plugin which changes a position of a facility, re-propagates a satellite or does something else that changes the state of the application. So what, one may ask? Well, changes to the object’s position will trigger the access computations and the access plug-in will be called again, and again, and again… To address this, we have introduced a "restricted" context which purpose is to provide a safe mechanism for accessing the STK object state via the Object Model while protecting its state. How does this work?
When accessing the STK Object Model configured using a restricted context, the users are given read-only access to the STK Object Model objects and their methods and properties. Any attempt to change the application state by calling a method or changing a property value will result in an exception. The diagram below shows the restricted STK Object Model Root object accessed by the access constraint plug-in. Any action via the Object Model will first consult the associated context and throw an exception in case if the action is marked unsafe. So, if you are writing an access constraint plug-in and intent to use the Object Model, beware of the restricted contexts.


Powered by WordPress