Best Practices

This topic describes the following best practices:

Command string uniqueness

Design command strings for uniqueness. The user of your plugin may have more than one UI plugin running simultaneously in ODTK. When someone clicks a custom toolbar button or menu item, ODTK will call Exec, not just for the plugin that the command pertains to, but in every active plugin. Your command strings need to be unique across all of those plugins. For this reason, AGI recommends a MyCompany.MyPluginName.MyCommandName convention, to help enforce that uniqueness.

Use string variables. For clarity, examples use literal strings in all function calls, string comparisons, etc. In practice, this can make it more difficult to change your command strings and debug your code. A better idea would be to use class variables for the command strings.

Working with toolbars

ODTK caches toolbar data. For this reason, changes to the plugin toolbar may not immediately show. In ODTK, go to Edit > Preferences > UI Plugins. Highlight the plugin of concern and then click Reset Toolbars.

ODTK uses workbook files to manage the display and placement of windows and toolbars. When you save a scenario, ODTK saves a corresponding workbook file, preserving information about which toolbars and buttons are displayed. There are also default workbooks that control both the default appearance of a new scenario and the appearance of ODTK when no scenario is loaded.

When no scenario is loaded, the ODTK default behavior is to display the toolbars of active plugins. When you create a new scenario, the ODTK default behavior is to display only the toolbars specified in the default workbook. For this reason, you will see your toolbar appear when you start up ODTK with no scenario, but once you create a new scenario, the toolbar is not displayed.

To display or hide a toolbar in ODTK, go to the View menu and select Toolbars. Select the listed toolbars to toggle them to either appear or go away. You can access the same toolbar selection menu by right-clicking in the empty space adjacent to the displayed toolbars.

Window management

ODTK keeps track of the state (docked, integrated, or floating), size, and position of windows. This is a usability feature that improves the user experience. Similarly, you may make similar adjustments to the forms in the UI Plugin. You may wish to capture this information when the window is closed, so that when the window reopens, it will appear in the latest settings for state, size, and position.

File management

Each ODTK scenario is composed of a stack of multiple files. Depending on the complexity and number of objects in the scenario, a single scenario could produce anywhere from a handful to a hundred or more files. For this and other reasons, best practice dictates that each scenario be saved in its own folder. Creating and naming a new scenario does not drive ODTK to create files for it. You must actively save the scenario. When you save the scenario for the first time, ODTK creates a new folder with the same name as the scenario and then saves the scenario and object files in the new folder.

If the UI Plugin creates or writes any files (aside from STK scenario or object files), ODTK will not save those files automatically; the plugin must manage this. Most external files will fall into one of these categories:

  • Files specific to a single scenario or object (e.g., an ephemeris file). You should save these files in the scenario folder. If no scenario folder exists because you did not yet save the scenario, you can save these files in a temporary location. Then either move them to the scenario folder upon an OnScenarioSave event or delete them upon an OnScenarioClose event.

    For files specific to an object, there may be additional considerations. For instance, if you delete the object or make changes to the object such that the file is no longer needed, you can have the plugin set to use the OnStkObjectDeleted and OnStkObjectChanged events to determine whether files should be deleted. Similarly, the OnStkObjectRenamed event is useful if, for instance, files are named according to the object name.

  • Files for use across two or more scenarios. You should save these files in a central repository of some sort. Files used by a single user across two or more scenarios may be saved in the ODTK User Directory. Files used by two or more users sharing a single computer may be saved in the Application Data or ProgramData directory.

For any files generated by the plugin, the programmer should carefully consider the scope of those files and what sorts of events should trigger a save or deletion.

Related Topics: