PFC 6.0 Most Recently Used Service
Page 1 of 3
The name for this service might as well be Most Frequently Used. Almost every standard windows application has the "Most Recently Used" feature. Word, Excel, and even PowerBuilder itself all append the menu items to the file menu to provide a quick access to the few last used items. See Figure 1 below:
Figure 1 - Most Recently Used in the Library Painter
If you are using PFC 6.0 you are now few keystrokes away from adding this feature to your application.
In this issue I will examine the fine points of implementing the MRU service, common pitfalls and possible areas for extensions.
What does the MRU service do? It is clear that it modifies the menu to append the names of the last used windows, but how does it know which menus to modify? How does it know what action to take when the menu is clicked? What if when opening a window I need to pass a parameter? How does it retain this information after the application is terminated? When should the menu be modified? On save? On open? On close? How do you handle all the possible choices? The fact is that the structure, navigation, and inter-window communication of most business applications are more complicated than those of Word or Excel. The answers to these questions may vary with each specific application. The MRU service handles the requirement uncertainty by providing a flexible API interface that allows the service user to specify specific service behaviour or action. A pessimists view of the flexible interface is that more code has to be written to enable and configure the service. As you will find out the MRU service configuration
requires slightly more effort than simply enabling the service. Dont worry, all is not lost. Later in the article I will point out some assumptions you can make to move the bulk of the service configuration code to the application or department framework layer.
MRU Service Configuration
The MRU is an application level service and is therefore enabled from the application manager constructor event.
The service provides an option of INI file or the registry to store the MRU data. The above code enables the service and configures it to use the user.ini file to store the MRU information.
The next step is to register the group ID(s) that will participate in the service. To better understand this option lets get back to the MS Word example. The Word saves one type of sheet a Word document. There is no question of which sheets should be added to the MRU menu. In contrast a typical business application deals with all kinds of different windows. For example, an application for the PB sample database may have an employee maintenance window, customer search, employee list, contact maintenance, each possibly with different requirements and interface options. Not all the windows may need to participate in the MRU service. Consider a requirement that an employee maintenance class menu should display the shortcuts only for the few last opened employee maintenance sheets as shown in Figure 2.
Figure 2 Exclusive MRU Group Mode
continued on ...
|This article was originally published in the April 98 issue of PowerTimes magazine. To find out more about PowerTimes visit their website at http://www.powertimes.com/|
Last revised: February 15, 2004 03:58 AM.