I define the following parameter in a report to enable a context to include a structure not within main.
<Parameters>
<Parameter name="PFpost" caption="Post" hint="2IS367">
<Values>
<ForEachPathReference path="/IRRS/IRSI/back::2IS370">
<AddValue/>
</ForEachPathReference>
</Values>
</Parameter>
</Parameters>
As I move back in the path, how to set the default parameter item? No part SIDs available to item as aproached with back. My script fail/hangs with message "Please sekect a parameter".
Jan Söderberg
When you are using Contexts you typically follow some simple patterns, like the "Simple cases" listed below.
Since these simple cases are the most common, it may lead you to think that this is the only way contexts can be defined.
However, the Context solution is both simple, yet also very flexible and powerful, and there are more advanced ways of defining context, ways that may not be too obvious. Some of these ways of using Contexts are listed below under "Unusual cases". These examples are not exhaustive, and there may be many more ways of using the construct. The key principle presented here is that the concepts used for defining Contexts can be used quite freely, to solve many different report needs.
Simple cases
Below is a typical simple Context design, listing all Sections of a Document.
When a parameter is used for selecting the Document context of a Section, it often looks like this:
Unusual cases
For one thing, the "main" group does not have to be used only as the top owner of a context. It can be used also on the "defobj" side to add additional items to the main group.
The below report will list all sections of a Document, but also the Document itself.
Note that the "+" option has to be used for the first use of the main group, since the group is already populated with the selected Section:
The above example also illustrates that the group attribute of the <ForEachInContext> may in fact use the "main" group.
The advantage of using main this way is that you can list all the Document Sections according to part #, as illustrated below:
(Note that in order to sort on PartNo, you have to be on a part, hence the use of <ContextGoForwardToPart>)
When a parameter is used, you are not limited to just replacing the "main" group with the parameter, but in fact the two groups can be combined:
In the Context visualizer this kind of context has a somewhat unusual topology:
The following example illustrates that a part group can be populated with different part types, similar to the case when we add different item types to a defobj group. In the example, both the Document and all its Document Sections sections will be included in the main group. What's more, the part "subSections" will include both the Document Section [IRRS] parts and the Sub Section [ISSE] parts.
This means that the report will list all sections of the document.