该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

Name := UserName

DocName := "Travel Request for " + Name + ", " + GetDate()

DocSumSet(DescriptiveType!; "Travel Request")

DocSumSet(DescriptiveName!; DocName)

DocSumSet(Author!; Name)

This fragment of code gets the users name (as set up in "Edit", "Preferences", "Environment" for each user), puts it and the current date into the DocName variable, sets the document summary "type" field to "Travel Request" as a document type, enters the document name into the title field (DescriptiveName!) of the document summary, and also sets the users name in the summary info. The DocName and Name variables are also available to be put into the document itself, if desired, by using the Type() macro function. I do this on every template I create, so the titles are automatically available in the file dialog without any effort on the part of the user.

Another reason I use macros instead of the prompt builder is to provide more specific field types for the data the user is to enter. The prompt builder makes all fields generic text fields. By using the Dialog Editor for a macro, you can define not only a more logical grouping of the fields (different sizes, shapes, locations), but you can use special purpose fields, such as a date field or file name field. A date field provides a pop-up calendar that the user can more easily use to enter a date; a monthly calendar pops up, and the user just clicks on the date desired (different months and years can be selected with buttons on the calendar view). Your macro gets back a date string that is already error-checked, since it must have been a valid date when chosen from a calendar. Similarly, if you want the user to enter a file name or directory that already exists, the file control provides a pop-up dialog for selecting the file, just like the dialog the user gets when opening a file for WPWin. Again, it is easier for the user to select the file name from the dialog, and the data is usually already correct (the file or directory exists) since it is selected directly from the users disk or network volume. You can also control user selections with radio buttons, check boxes, drop-down lists or list boxes, etc. If you want to make sure the user enters only one of a particular list of text strings, you can use a drop-down list and pre-define what goes into the list. These not only simplify the users selections, since the possible choices are specifically listed, but it ensures that only valid options are selected for your document or form.

Template vs. File Macros -- Which to use?

When used with corporate LAN-based templates, I select the type of macro based on how it will be used, depending mostly on maintenance issues. If the macro is general purpose, usable for more than one template (the type I usually try to write), the choice is obvious -- make it file-based so you can have one copy in the central macro directory, and any updates will correct all templates with one macro file change.

If the macro is small and is applicable only to a single template, and the template is not used frequently, keeping the macro as a template macro makes sense since it is kept with the template in one file. Also, if the template is one that users are likely to take home with them to use, keeping macros with the template makes it easier for the user -- only one file has be to copied to the home PC, and updates to the macro(s) are kept in sync with the template (updating the users template also keeps the corresponding versions of the macros with it).

However, be aware that on a central LAN-based system, all users who have used a particular template must exit from WPWin before that template in the common LAN directory can be updated. Otherwise, a file sharing error will be encountered ("file in use" type network error) while trying to overwrite the template file with an update. This can be particularly annoying with templates that are frequently used -- it is difficult to get everyone out of WP at the same time in order to do the update. This can mean after-hours efforts. For this reason, many macros that might be updated periodically would benefit from being maintained as a file macro, so you can update the macro without having to coordinate updates of the template. Macros are not kept open as long as templates, since the template is kept open as long as the user is working on a document based on that template. Also, it has been my experience that not only must the user exit the template document, but a complete exit from WPWin is needed before the template can be updated.