This section should only be read by database administrators who are setting up window configurations for their users.
Screen templates are files that contain window setup information captured by the screen_template_export script. In addition to the windows, other information that affects the user experience is also exported. This includes any bookmarks that were set and also the pick roots configured for the user (pick roots control what information a user can pick for various fields such as which accounts he can post to).
Screen templates are created for a particular database. That is, a when you create a screen template from an application database, NewViews will only attempt to use (i.e. import) that screen template with the same application database. The idea is for one user to create a set of windows, bookmarks, etc., that will be useful for other users of the same application database.
Screen templates are used automatically by NewViews. There is no corresponding screen template import script that you have to run.
Screen template files are kept in the screen templates folder: c:/nv/screen_templates where c:/nv is assumed to be the NewViews installation folder. Screen template files have the extension .nv2_screen_template. Template files are automatically given a file name that includes the database id and the date/time exported, but this information is rarely of use.
Screen templates are used in only two circumstances. The first is when a user opens a set of books for the first time (from a particular workstation). NewViews searches for an appropriate screen template and automatically imports it to set up the windows for the user. The second circumstance is created artificially using the workstation_login_screen_delete script. If you position on a row in a workstation and run that script, the screen for the database and user is deleted, essentially simulating the situation where the user has never opened that database, and therefore causing the screen template to be used.
When you run the screen_template_export script, NewViews will export a screen template file to the template folder. If there is already a file there that matches the database id and user access, then that file will be replaced. You are prompted to confirm file replacement but that is just a formality. You typically always want to replace the previous screen template file.
You might also export a screen template to a location that can be accessed by a number of users in a multi-user environment. Users can then copy the screen template file to their own screen_templates folder.
Set up windows the way you want them.
You set up preferred window positions, sizes and columns, etc. The state of your windows will be captured in the exported template, and resurrected in the target workstation when imported (automatically by NewViews). This ability can be used to ease configuration and provide consistency among users.
Also set up any bookmarks and pick roots that would be of use.
Issue the File>SaveAll command.
To ensure that the exported information accurately reflects what you just set it up, save the workstation data.
Issue the Tools>Script Evaluate command and select the script.
The script is c:/nv/nv2.dat/scripts/screen_template_export.qw_script. It should appear when you click <List> but if you don't see it in the list, click <Browse> to pick it from a file explorer.
Confirm that you want to replace a previous screen template file.
NewViews will find the previous screen template files that match the database and user. You are prompted to replace them, which means they will be deleted before exporting the new file.
The file name for the screen template is set automatically by NewViews and the extension will be .nv2_screen_template. It is exported to the screen templates folder: c:/nv/screen_templates where c:/nv is assumed to be the NewViews installation folder.
An exported template file is a flat text file that can be viewed but it is not recommended that you do not edit it.
The real work behind the export is preparation. To prepare, you navigate through your application database setting up windows the way you want them. When you are satisfied perform the export. Here are some techniques, pointers, and guidelines.
Configure the ledgers of various account classes.
Position on the root account in a tree explorer (left pane). Position the right pane on the setup view. Click on the line number title. This should result in 11 lines in the right pane, one per account class counting the total and root account classes. Split the right pane, positioning the bottom pane on the ledger. Click on each account in the top pane and configure it's ledger in the bottom pane.
How you configure your windows is entirely up to you. That's really the main point of this exercise. What some people do is click on the date column title to put the ledger in reverse date order (later dates toward the top). Then you might position on the first ledger item. Repeat for each account class in the top pane.
Set up your reports.
Visit your reports and set up the columns and the header dates and analysis resolution etc. This makes life a bit easier for users who import the template.
Set pane sizes appropriately.
Maximize windows where desired and when splitting panes adjust the divider to useful ratios. If you are really picky you can even adjust the dividers to land perfectly on line boundaries so lines are not partially displayed.
Issue the File>Save All command before running the script.
This ensures your window setups are saved and that the saved versions will be used during the export.
Screen templates are dependent on a user's security configuration, i.e. the objects to which the user has been granted access. When you export a screen template, this security information is exported as well. When you import a screen template, the current user's access setup must match the access in the template file. Otherwise the import is rejected with an error message. When NewViews searches for a screen template it automatically matches the access information in the template to the current user's access in the application database. Any templates whose access does not match is skipped. If no template is found, then NewViews reverts to basic built-in default configuration.
For example, when you export a screen template, if you are the administrator, or any other user with access to the root object, then the exported template file will be skipped unless the importing user has access to the root object. Or if the exporting user is an operator with access to the root customer account and the sales journal, then only other similar operators with the same access will use the screen template. After consideration you might begin to realize that this is more of a feature than a limitation. Note also that it's another reason to take care when naming your export files.