Browse Prior Art Database

Efficient Cached Menu Processing When an Application Fails to Load Properly

IP.com Disclosure Number: IPCOM000113571D
Original Publication Date: 1994-Sep-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 89K

Publishing Venue

IBM

Related People

Malcolm, JW: AUTHOR [+2]

Abstract

LAN NetView* View provides registering applications with very powerful capabilities for dynamic menu creation and menu item additions. Because the menus are dynamic rather than static, they need to be created from scratch whenever they change, such as due to another application registering new menu items on a View menu. To avoid the performance delays caused by creating the menus each time they are requested, the menu definitions are cached to disk. The cached definitions are used for all subsequent menu display requests until new menu items are added or the registering applications are changed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Efficient Cached Menu Processing When an Application Fails to Load
Properly

      LAN NetView* View provides registering applications with very
powerful capabilities for dynamic menu creation and menu item
additions.  Because the menus are dynamic rather than static, they
need to be created from scratch whenever they change, such as due to
another application registering new menu items on a View menu.  To
avoid the performance delays caused by creating the menus each time
they are requested, the menu definitions are cached to disk.  The
cached definitions are used for all subsequent menu display requests
until new menu items are added or the registering applications are
changed.

      When a menu needs to be rebuilt, its cached data is marked as
invalid.  Therefore when it is next read from disk, rather than being
used as read in, it is rebuilt, re-cached, and marked as valid for
future use.

      A big problem with this design exists when an application
registers new menu items and then is unable to be loaded at runtime.
When a new application is registered with View, an affected cached
menu is invalidated so it will be rebuilt when the menu is next
requested.  This invalidation takes place at registration time, not
runtime.  The application can fail to load at runtime, however,
because its DLL file is not found, or it is found but the class is
not loadable for some reason.  In this situation its menu items will
not be added to the menu.  The menu will still be rebuilt and
rewritten to disk and validated, however, so it will not be rebuilt
when the problem that caused the application to not load is later
fixed.

      This disclosure describes a technique that allows cached menus
to handle this situation in an efficient, user friendly manner
totally transparent to the application.

      The solution to this problem is found in the application load
and menu caching processes.  When View is started, it attempts to
load all registered applications.  If any registered application's
class is not successfully loaded, then a flag needs to be set in the
global storage common area to indicate this condition.  The loading
of applications, and thus the setting of this flag if any fail to
load, is done before any menu processing is required.

      Each time a menu is requested to be displayed, this flag will
be checked.  If the flag indicates that a load failure occurred,...