Pro/ENGINEER: Anatomy of a Trail File, Part 3

Read Part 2

In my experience, there are three main uses for trail files: Recovery, Benchmarking, and Templating. Generally speaking this series of articles is about templating trail files. Templating is the modification of trail files to perform actions that are not specific to a particular model.

In more complex trail files, selection of items eventually becomes a necessity. Doing this in a repeatable way can become very challenging, especially if working with different models or models that are changing often.

Selections of models, features, annotations, and notes can be accomplished in various ways, but selections of geometry items such as surfaces and edges are very difficult in such a manner that it works for different models. Trail file selections using the graphics window are almost never transferable for use with other models.

Model Tree

When you click on an item in the model tree, you'll see, for example, "node4" or "node31" appear. Here is an example of a trail file entry caused by selecting 'Note_1'.

~ Select `main_dlg_cur` `PHTLeft.AssyTree` \
1 `node6`
!Note_1

 
These node numbers are assigned by Pro/ENGINEER on a first come, first served basis. When the model is first opened the node numbers are assigned in a bottom first, upwardly increasing sequence, based on what is displayed at that time.

For example, if the model tree of a part is shown with features and annotations when the model is opened, the following table reflects the node number assignments. The top level item (the part itself) is node 0 (zero), then working up from the bottom the node numbers increase. As you can see, even the 'Insert Here' pointer has a node number.

 Item        Node #
ABC.PRT        0
 Note_0        8
 Note_1        7
 Note_2        6
 Feat1         5
 Feat2         4
 Feat3         3
 Feat4         2
 Insert Here   1

 
The tricky part comes when new nodes are shown either through expansion of existing nodes (i.e. to show features of a component) or modification of the model tree filters. Regardless of where in the model tree they appear, the new nodes are given new node numbers based on the previous largest value.

As an example, if your model tree initially shows nothing, then annotations are added, then features are added, you might get a result like this:

 Item        Node #
ABC.PRT        0
 Note_0        3
 Note_1        2
 Note_2        1
 Feat1         8
 Feat2         7
 Feat3         6
 Feat4         5
 Insert Here   4

 
The node numbers for a complex assembly might even appear to be randomly assigned. Disappointingly, use of 'Expand All' doesn't produce very orderly node number assignments.

Beyond the top level nodes, use of the model tree can be very complicated. It is definitely something that can be done, but requires some preprocessing to generate a trail file programmatically before it is run. Most likely, trail files making more than trivial use of the Model Tree will not be usable for other models.


Search Tool

Another approach to selections with trail files is the "Search" tool (i.e. Edit -> Find). The Search tool works very well when selecting items with a trail file. Selections of specific models, features, or numerous other entities can be accomplished easily.

The downside to this approach is that you lose some control over where in an assembly hierarchy objects can be located. An option exists to search only in the top level, but an 'All Levels' search will return results from any level.

Another difficulty is that multiple results will be obtained when searching for common objects, such as hardware parts, shared subassemblies, and models with standard features, etc. There is a mechanism to select specific items, but this requires a great deal of information that has to be provided ahead of time.


Defaults

Another thing to keep in mind is that the last option you use in the Search Tool may be the default option when the Search Tool is used a second time. A recommendation is always to set explicitly every option (even if it is the default) every time the Search Tool is used with a trail file. This will produce more robust trail files.

It may be extra work to click on other options that you don't want in order to record the selection that you do want, however it's worth the effort. Extra baggage code in the trail file can usually be removed, if that is desirable.


Example

A typical scenario is the need to select an item such as a component, a feature, or a note using its name. Here is an example of using the Search tool to search an assembly for a subassembly called 'A.ASM'. I have added comments to indicate the major sections.

!! Start the Search tool
!!
~ Select `main_dlg_cur` `MenuBar1` \
1 `Edit`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `Edit.Find`
!!
!! Select entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Limit search to top level
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0
!!
!! Enter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`A.ASM`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Selecting item(s) in results
!!
~ Select `selspecdlg0` `ResultList` \
1 `-1:69:[39]`
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`

 
If you follow along in your trail file while performing the search, you can see that each action produces a certain output, which is mostly self explanatory. What is not so obvious is the syntax of the output when items are selected in the search results.


Selections

The syntax used for selection of components differs from the selection of other types of entities, but it is similar. The `-1:69:[39]` specifier is a colon separated list of three fields: ID, Type, Component Path.

The first field is an item ID field (i.e. feature id, note id, etc), except for components where it always shows -1. The second field is a numeric code corresponding to the type of entity in the search, whether that be 'Feature', 'Annotation', 'Component', etc. The third field specifies a "Component Path" which is a list of component feature IDs from a top level to a subassembly or component. The "[39]" indicates that the selected component is feature ID 39 in the top level assembly.

A selected item generating this syntax `2:147:[40][40][41][61]`, is a note (or some other annotation) with id 2 and found through the component id sequence of 40 (level 1 component id), 40 (level 2 component id), 41 (level 3 component id), 61 (level 4 component id).


Select All

The "Select All" action (Ctrl-A) can be used at any time and generates the following trail code. Even if a selection of an item is required for an interactive user prior to using "Select All", this can be used without it in a trail file.

~ Select `selspecdlg0` `ResultList` \
-1

 

Depth

The depth of the search is controlled by the "Include submodels" option in the Search Tool dialog. Checking or unchecking this option adds one of the following code sequences to the trail file.

!! Limit search to top level ('Include submodels' is not checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0

 

!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1

 

Closing The Dialog

As you can see from my comment, hitting Close in the dialog adds a curiously named "CancelButton" entry. Just remember if you're editing the trail file, that this means "Close".

!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`

 

Types

One of the first things typically done when using the Search Tool is the choice of entity type. If you're familiar with the tool, you know that there is a very wide range of type options to choose from.

Type selection generates code such as this:

~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `TYPENAME`

 
Some examples of `TYPENAME` are `Prt_or_Asm`, `Component`, `Feature`, `Annotation`, `Note`, `Location`, `Datum`, `3D Curve`.

As discussed earlier, the numeric code for the type is reflected in the code generated when selecting items in the search results. The type code for `Annotation` and `Note` are both 147, while `Prt_or_Asm` ("Solid Model" from the GUI) and `Component` are both 69.


By Name

The Search Tool allows case-insensitive name searches, and wildcards can be used to make the search criteria more generic. The basic syntax is as follows:

~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`NAME`

 
Examples of `NAME` with and without wildcards might be `12345678_OBSOLETE.PRT`, `DEFAULT`, `ASM_TOP`, `ASM_*`, `*65-5*`, `*side*`.


By ID

If a specific feature ID or note ID is known, this can be searched for as well. This appears in the GUI under the "History" tab and generates the following entry:

~ Select `selspecdlg0` `RuleTab` \
1 `Misc`
~ Select `selspecdlg0` `RuleTypes` \
1 `ID`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicIDLayout.InputIDPanel` \
`IDENT`

 
Where `IDENT` is an integer number such as `1`, `2`, `3`, etc. Note that the History tab goes by the name of Misc in the trail file. All other tabs follow their name in the trail file more directly.


By Parameter Value

In addition to entity name searches, the Search Tool can perform searches based on parameter values, using the "Expression" radio option in the "Attributes" tab. Keep in mind that there are differences in the behavior of "Component" searches versus "Solid Model" searches. Testing will ensure your searches produce the desired results.

This sequences will prep the dialog box for searches based on parameter values:

~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`

 
The type must be selected first (real number, string, integer, yes/no), then the name of the parameter. Be careful when selecting the parameter name from the drop down list, because only a sequence number will be recorded. For a different set of models, the sequence number may not correspond to the same parameter name as when you recorded the trail files.

This results from choosing a parameter from the list:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`

 
This results from typing in a parameter name:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DES`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`

 
The typed syntax can be simplified, by removing the 'Input' entries and leaving the 'Update' entry, to this:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`

 
The 'Value' field in the dialog box corresponds to the 'ExprValuesList'. Any value can be entered, and wildcards can be used as well. Note that string searches seem to be case insensitive only when used with wildcards.

~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`

 
The "Comparison" can be changed from the default of "is equal to". There are seven operators available, with this being an example of greater than (more useful for numeric comparisons):

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel` \
1 ` > `

 
The list of comparisons (for ExprOperandLabel) is:

` == `   is equal to
` != `   is not equal to
` < `    is less than
` > `    is greater than
` <= `   is less than or equal to
` >= `   is greater than or equal to
` * `    exists
` !* `   does not exist

 
When searching by parameter, the parameter type must be selected first.

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `TYPEID`

 
Where `TYPEID` is 50, 51, 52, or 53 for Real Number, String, Integer, and Yes/No, respectively.


Look In

The 'Look In' drop down list allows for user control of the model (or hierarchy) to be searched. Here are some examples of selections made from the drop down list.

Top level selected:

~ Input `selspecdlg0` `LookInDrop` \
`12345678.ASM`

 
Component selected:

~ Select `selspecdlg0` `LookInDrop` \
1 `12345678_SKEL.PRT (12345678, id 43) (43)`

 
It is also an editable field in which you can attempt to enter model names. Unfortunately, the rather strong autocomplete nature may prevent entering the correct model name, or stop at another model, or result in garbage entered. None of this will produce a useful trail file.

The good news is that the syntax used for top level example can be used for any model at any level:

~ Input `selspecdlg0` `LookInDrop` \
`23456789.ASM`

 
This differs from other trail file entries in that typically the "Update" statement is kept while the "Input" entries are eliminated, because they are typically redundant. It is most likely the autocomplete functionality that makes this necessary.

When using this syntax, which lacks the component path (list of component ids), you'll lose some control if the model is used multiple times in an assembly hierarchy. Not a major problem, just something to be aware of. Based on my testing, the Search Tool uses the model that appears last in the model tree, if multiples exist.


Tabs

A specific tab in the Search Tool dialog can be selected using the following example:

~ Select `selspecdlg0` `RuleTab` \
1 `TABNAME`

 
Where `TABNAME` is `Attributes` for the Attribute tab, `Misc` for the History tab, `Status` for the Status tab, and `Geometry` for the Geometry tab.


Another Example

Combining several of these elements, here is an example that searches for parts and assemblies within all levels of ASM0002.ASM that for parameter DESC have a value matching "brack*", selects all found, and closes the dialog:

!!
!! Start the Search tool (via Ctrl+F)
!!
~ Activate `main_dlg_cur` `ProCmdMdlTreeSearch.edit_t`
!!
!! Select "Solid Model" as entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Restrict search to a subassembly
!!
~ Input `selspecdlg0` `LookInDrop` \
`ASM0002.ASM`
!!
!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1
!!
!! Go to "Attributes" tab, select "Expression" radio button
!!
~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Activate `selspecdlg0` `selspecdlg0`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`
!!
!! Select "String" from parameter value type pull down
!!
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`
!!
!! Enter parameter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
!!
!! Enter parameter value search string
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Select all in search results
!!
~ Select `selspecdlg0` `ResultList` \
-1
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`

 

Both the Model Tree and Search Tool are useful when used in trail files. Use of the Model Tree is more limited because it requires knowledge of its contents before the trail file is generated. The Search Tool, when used properly, provides one of the most robust methods of performing selecting with trail files. With minor editing, trail files utilizing the Search Tool can be generated quickly, easily and can be applied to a wide range of models.


Next time: Mapkeys and Trail Files

Pro/ENGINEER: Anatomy of a Trail File, Part 2

Read Part 1

Recording/Editing Techniques

Trail files are often touted as a crash recovery mechanism. While they can serve this function in very limited circumstances, they are usually not that helpful for this activity. For repetitive tasks, however, trail files are extraordinarily helpful.

To make them extraordinarily helpful, trail files must be recorded and edited very carefully. Right out of the box, Pro/ENGINEER doesn't record very efficient trail files. They will function, but can be excessively verbose and difficult to edit.

Here is an example of a trail file segment that opens a part file. It's a good example of how not to record trail files. Generally speaking, avoid typing in names when you can select them.

~ Select `main_dlg_cur` `MenuBar1` \
1  `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_open`
< 2 0.256000
~ Input `file_open` `Inputname` \
 `a`
~ Input `file_open` `Inputname` \
 `ab`
~ Input `file_open` `Inputname` \
 `abc`
~ Input `file_open` `Inputname` \
 `abc.`
~ Input `file_open` `Inputname` \
 `abc.p`
~ Input `file_open` `Inputname` \
 `abc.pr`
~ Input `file_open` `Inputname` \
 `abc.prt`
~ Update `file_open` `Inputname` \
 `abc.prt`
~ Activate `file_open` `Inputname`
!Command ProCmdModelOpenExe was pushed from the software.
!15-May-08 17:39:09  Start ./abc.prt.2
!15-May-08 17:39:11  End   ./abc.prt.2

 
Compare this against a trail recorded by selecting (not typing) the name of the model to open, and using the config.pro option CMDMGR_TRAIL_OUTPUT set to YES. This option is meant to simplify trail file output and make the menu picks less dependent on the menus. If Tools / Customize Screen is used to move menus around, this mapkey will continue to work, but the previous one might fail.

~ Command `ProCmdModelOpen` 
< 2 0.256000
~ Select `file_open` `Ph_list.Filelist` \
1  `abc.prt`
~ Activate `file_open` `Open`
!Command ProCmdModelOpenExe was pushed from the software.
!15-May-08 17:36:11  Start ./abc.prt.2
!15-May-08 17:36:16  End   ./abc.prt.2

 
As you can see the results are much simpler. In fact, following the rules from Part 1, four of the eight lines can additionally be reduced:

~ Command `ProCmdModelOpen` 
~ Select `file_open` `Ph_list.Filelist` \
1  `abc.prt`
~ Activate `file_open` `Open`

 

There will be times when you need to automate something using an existing trail file but you either don't have the luxury or the desire to re-record the trail file. In this case you want to eliminate the fluff, but keep the necessary elements. From the verbosely recorded sequence, the following can be completely eliminated:

~ Input `file_open` `Inputname` \
 `a`
~ Input `file_open` `Inputname` \
 `ab`
~ Input `file_open` `Inputname` \
 `abc`
~ Input `file_open` `Inputname` \
 `abc.`
~ Input `file_open` `Inputname` \
 `abc.p`
~ Input `file_open` `Inputname` \
 `abc.pr`

 

Of the remaining lines, the first two can typically be eliminated.

~ Input `file_open` `Inputname` \
 `abc.prt`
~ Update `file_open` `Inputname` \
 `abc.prt`

 

Which leaves this as a result:

~ Update `file_open` `Inputname` \
 `abc.prt`

 

When you are replaying a trail file without changing the model used (i.e. for running a benchmark), a lot of these edits are not required. When you are using the trail file as a template for different models, these type of edits are very important, making it much easier to adapt the trail file.


Next time: Robust selection techniques with trail files

Pro/ENGINEER: Anatomy of a Trail File, Part 1

Trail File Basics

Despite a diverse set of API's, Pro/ENGINEER trail files represent a reliable and robust method of automating Pro/ENGINEER activities. They are not the perfect fit for every application, but for many needs they work great.

Trail files are best used after recording specific actions, then combining the resulting content to create the finished trail file. In order to edit trail files it is important to understand their content.

Here is an example of a trail file header. These entries are generated by Pro/E upon startup without any action from the user. The first line is always present and always required in your trail files. Some other lines that stand out indicate that Wildfire 2 was used and the ProE to JT Translator is started via a protk.dat file. Both of these are status messages and are not required.

!trail file version No. 1301
!Pro/ENGINEER  TM  Wildfire 2.0  (c) 2004 by Parametric Technology Corporation  All Rights Reserved.
< 0 1.135407
< 0 0.964741
< 0 0.879000
< 0 0.842000
!Application (VisProducts): started via registry.
!    exec path: /opt/UGS_JtTranslators/ProE/EAI_Proe/proe/sun/proclientWF2
!    type: synchronous Pro/TOOLKIT EXE
< 0 0.846000
~ Move `splash_dlg` `splash_dlg` \
2 7.472141 6.432063

 

I have never needed to keep lines that start with the 'less than' symbol and typically always remove them if piecing together a trail file:

< 0 1.135407
< 0 0.964741
< 0 0.879000
< 0 0.842000

 

As the lines relative to the 'splash_dlg' are unnecessary, all that is needed from the above is this:

!trail file version No. 1301

 

Although we don't need the lines associated with the 'splash_dlg', the syntax is important to understand as it is used throughout trail files. The trail file 'interpreter' sees the backslash continuation character (\) as an instruction to treat the following as a single line:

~ Move `splash_dlg` `splash_dlg` \
2 7.472141 6.432063

 
If the entry is to be removed, both lines should be removed, or the trail file will not work. Don't try to combine the lines. That won't work either. If you need the entry, leave it as is. The interpreter can handle it, and you shouldn't worry about it consuming more than one line.


Another note in the JT Translator startup messages is that they start with an exclamation point. This is the 'comment' indicator, instructing the interpreter to ignore the line. All lines starting with an exclamation point are not needed and can be removed, if desired. In some cases, I'll leave a comment in place to help identify the end of an action, but typically they are removed.

To assist in editing trail files, I usually add comment lines before and after sections. This makes it very easy to copy or move sections within the file.

!!!
!!! Run massprop calculation
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `Analysis`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `Analysis.psh_analysis_modelanl`
~ Activate `modelprop` `Compute`
!%CIMass Properties calculation completed.
~ Activate `modelprop` `Close`
!!!
!!! Exit session
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_exit`
! Message Dialog: Warning
!               : Do you really want to exit?
~ Move `UI Message Dialog` `UI Message Dialog` \
2 14.561095 12.836755 
~ FocusIn `UI Message Dialog` `no`
~ FocusIn `UI Message Dialog` `yes`
~ Activate `UI Message Dialog` `yes`
!End of Trail File

 

Part 2: Recording robust trail files

Intralink Scripting: Creating Pro/ENGINEER Trail Files in Java

If you're trying to automate some Pro/ENGINEER activity, the use of trail files is a solid and reliable method. Whether you are trying to automate interference checks, convert files to ProductView or PDF, or just verify a large number of family tables, trail files work great. This is assuming that you don't need any interaction between Intralink and Pro/ENGINEER, during the trail file execution.

The first thing you need is a trail file template. This is simply a trail file that you have recorded. The content will be changed slightly to include variable names where real values will be substituted at runtime.

For example, this:
~ Activate `main_dlg_cur` `ProCmdModelOpen.file`
~ Select `file_open` `Ph_list.Filelist` \
1 `abc.prt`

Becomes this:
~ Activate `main_dlg_cur` `ProCmdModelOpen.file`
~ Select `file_open` `Ph_list.Filelist` \
1 `@NAME@`


One thing to note about trail files, they contain a lot of "fluff", which are lines that you don't need, but got recorded. You won't know what you need and don't need until you try to remove it. My advice is to comment lines you think you don't need, by placing an exclamation point as the first character of the line. Pro/ENGINEER will ignore these lines. If the trail file plays as expected, the line is probably not needed.

This means that any line starting with an exclamation point can be eliminated. The one exception is the first line of the file. You need this, don't remove it. Generally, I leave some of the commented lines that were originally recorded in order to remind myself when an action has started or finished.

There is a config.pro option that will help prevent trail file fluff. Set CMDMGR_TRAIL_OUTPUT to YES and Pro/ENGINEER will reduce the number of lines and increase readability substantially.

Here is an example of a trail file template that records a timestamp, opens a file, records another timestamp, and then exits. You'll notice the comments indicating "blocks" of actions.

!trail file version No. 1301
!!!
!!! Timestamp
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `Info`
~ Select `main_dlg_cur` `Info.cb_info_session`
~ Close `main_dlg_cur` `MenuBar1`
~ Close `main_dlg_cur` `Info.cb_info_session`
~ Activate `main_dlg_cur` `psh_util_time`
!!!
!!! Open model
!!!
~ Activate `main_dlg_cur` `ProCmdModelOpen.file`
~ Select `file_open` `Ph_list.Filelist` \
1  `@NAME@`
~ Activate `file_open` `Open`
!Command ProCmdModelOpenExe was pushed from the software.
!!!
!!! Timestamp
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `Info`
~ Select `main_dlg_cur` `Info.cb_info_session`
~ Close `main_dlg_cur` `MenuBar1`
~ Close `main_dlg_cur` `Info.cb_info_session`
~ Activate `main_dlg_cur` `psh_util_time`
!!!
!!! Exit
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_exit`
! Message Dialog: Warning
!               : Do you really want to exit?
~ FocusIn `UI Message Dialog` `no`
~ FocusIn `UI Message Dialog` `yes`
~ Activate `UI Message Dialog` `yes`
!End of Trail File

Now that we have a template, we need some java code to create the trail file that Pro/ENGINEER will run. There are many Java templating libraries that do some very complex manipulations, but for this simple example, we need very simple substitutions. The code listed below is quite simple, but works great for basic trail file creation.

Once variables have been established, the first task is to generate file handle objects for reading (using the BufferedReader/FileReader classes) and for writing (using the FileWriter class). Each line of the template file is read from using readLine() in the while loop. Then the value of the objName variable is substituted where @NAME@ is found in the template. The resulting line is written to the output file. Closing both the input and output file is very important, especially on Windows, to make them fully accessible.

String text;
String inputFile = "trl-template.txt";
String outputFile = "trl-output.txt";
String newline = System.getProperty("line.separator");

// Set up input and output files
BufferedReader templateInput = new BufferedReader(new FileReader(inputFile));
FileWriter trailOutput = new FileWriter(outputFile);

// Read through all lines in file
while ((text = templateInput.readLine()) != null) {

    // Replace @NAME@ with objName String
    text = text.replaceAll( "@NAME@", objName );

    // Output modified template line to given output file stream
    trailOutput.write(text + newline);

}

trailOutput.close();
templateInput.close();

Following best practices, the code should be placed in its own function, or, even better, its own class. Also, using an array or HashMap, instead of a simple String object for input, would allow for more extensive substitutions to occur during trail file generation, but the above is the core of a simple approach that works very well.