The AppSearch action is typically used to search for a file on the target system, and populates the value of a public property with the full path to the file if it exists. (AppSearch can also be used to read data from the registry or an INI file in [WindowsFolder], but it’s not really “searching”.) A record in the AppSearch table contains the name of the public property to be populated with the results, and the primary key of a record in the Signature table; which in turn contains the file name, along with an optional range of acceptable versions, range of sizes, range of dates, and a language for the file. In addition, the DrLocator table—not sure why it’s not the “DirLocator” table—specifies the directory and number of levels of its subdirectories in which to search.
The AppSearch table is processed by the AppSearch action, which occurs early in the UI sequence. (Also early in the Execute sequence, in case of a silent or other non–full UI installation, but never mind that for now.)
Naturally, AppSearch can take a while to execute, so it’s a courtesy to display information about what’s taking so long. To handle this, schedule a modeless dialog in the User Interface sequence before AppSearch (in the UI sample from the Platform SDK, the corresponding dialog box is called “PrepareDlg”). On this dialog box, you can place Text controls that subscribe to the ActionText and ActionData control events. Finally, in the ActionText table, specify appropriate values for the AppSearch action.
In the following figure, the AppSearch record in the ActionText table has the text beginning “ActionText says:” in the Description field, and the text beginning “ActionData says:” in the Template field.
The ActionData/Template value doesn’t add much to it—just diplaying the property and signature names—so nobody would blame you for leaving it out.
No comments:
Post a Comment