Sw4   >   Misc   >   Cached Lists and Module Data

Cached Lists and Module Data

Cached lists contain additional information about your StudioWorks application.

  1. SQL Meta-Data
  2. Window Instances
  3. Window Menu Lines
  4. Navigation Menu Lines, groups, and subgroups
  5. Report Instances
  6. Icons List
  7. String Tables

Cached lists are stored in the oModuleData objects classes. StudioWorks automatically creates an oModuleData object in a library when needed. Each module stores its own portion of each of the cached lists in its own oModuleData object. The oModuleDataTool is used to access the module data.

Cached lists save a lot of startup time. For larger applications it would take a lot of time to build the cached lists and the string tables cached list on startup.

When you open your app, StudioWorks loads the cached lists using the oModuleDataTool object class. The portions of each cached list which are stored in all of the libraries are merged together into master cached lists that are used by the application. The master cached lists are accessed through the applicable tvars. (lsts, stb, rprts, icns, etc.)

  1. SQL Meta-Data list - held in memory in oSQLLists instantiated by the lsts tvar.
  2. Window Instances list - held in memory in oWindows instantiated by the wn tvar.
  3. String Tables - held in memory in oStringTables instantiated by the stb tvar.

The Programmer Workbench is where you can view and edit the cached lists. When you make changes to a cached list item in the Programmer Workbench the changes are immediately saved to the oModuleData object of the applicable library. This is done so that you won't (shouldn't) lose any cached list changes made if Omnis Studio should crash on you.

Some cached list changes cascade to other cached lists. e.g. If you change the name of a schema class column, it could affect numerous query classes, and it will affect the string tables. The Programmer Workbench does its best to do the cascading updates for you, but you may find a situations where it doesn't correctly cascade the changes. Please report these situations with as much details as possible so that they can be corrected in the StudioWorks framework.

If you add a SQL class (schema or query) in the Omnis Studio IDE the cached lists will not be aware of the new SQL class. In order to add the SQL class to the cached lists you will need to click on it in the SQL Meta-Data window of the Programmer Workbench. When you click on the new SQL class, the StudioWorks framework realizes it doesn't have that SQL class in its cached list and immediately adds the SQL class and its columns to the cached lists with all of the default values and saves it to the the SQL class' source library oModuleData object. As you make changes to the SQL class' meta-data each of the changes is saved back to the oModuleData object.

Tip

If you are not using the VCS you should set the $alloweditifnotcheckedout Omnis Studio preference to kTrue. This will save StudioWorks from having to first test cascading updates to make sure any affected classes are checked out before actually doing the cascading updates. It will cut the time for cascading updates in half.

In pre-2008-07-31versions you were editing code or meta-data and then building the cached lists from your code or meta-data. As of the 2008-07-31 release you are now directly editing the cached lists, negating the need to 'rebuild lists'. In some cases it might feel a bit sluggish editing module data in the Programmer Workbench, but you are saving loads of time by not having to constantly rebuild cached lists.

If you want to see what is really in the cached lists, select the Cached Lists tab in the Programmer Workbench. This shows you exactly what is currently in each cached list. You can shift+click on any of the tabs in the Programmer Workbench to open the tab's subwindow in a stand alone window. The cached list window contents are refreshed each time the window comes to the top.