Cues are a simple representation of the results of a query. They show the number of records returned by that query and, optionally, some aggregate data from those records.
A cue group is a part that displays one or more cues. Cue groups can be found in two places, on a role center, helping direct a user to what is important, (for example, quickly navigating to the list of orders on hold for a key customer), and also on a form, providing navigation to data related to the current record.
A good example of a cue group is on the All customers list page, which shows four cues, as shown here:
Cues require a menu item that targets the destination form and a query. The query can be the form's standard query, or one with additional filters and even additional data sources. The restriction is that the query must be compatible. This means that the root data source must be the same and it must have the same child data sources within its definition. We are free to add ranges to any data source in the query if we want to show a subset of data.
To ensure compatibility, we should use composite queries wherever possible, as these restrict us to only adding ranges. These are covered in Chapter 6, Extending the Solution.
Although cues show aggregate data (quantity and optionally value), they are intended to take you to a form, which is typically a list page. The system determines the query from the menu item associated with the cue using the menu item's Query property. To show data filtered to our needs, we need to create a query and a menu item first.
We will create a cue to show the service history of the vehicle and also the associated appointments. We will also create a preview part that shows summary information about the vehicle's service history, which may be all the user needs to see and will avoid having to navigate away from the vehicle form.
In the case of a vehicle service list page, the target form's data source has a direct relation with the vehicle table. In this case, we need a menu item that references the target list page and a query.
The existing vehicle services menu item references the right form, but not a query, so we need a new menu item. This can be created by duplicating this menu item and associating it with the list page's query. We don't need to filter this beyond the current vehicle record, so using the list page's query is fine. Should there be a need, we could supplant the query on our menu item at that point.
We then create a cue referencing the menu item and add it to a cue group. It is the cue group that we add to a form, again via a menu item. The following steps are the way to do this:
ConFMSVehServiceTableListPage
display menu item and select Duplicate.ConFMSVehServiceTableListPageCue
.ConFMSVehServiceTableListPage
.ConFMSVehServiceTableListPageCue
.Vehicle services
and locate the label.ConFMSVehServiceTableListPageCue
.ConVehicleRelatedInfoCueGroup
.Related information
and create a new label.ConFMSVehServiceTableListPageCue
onto the new cue group.ConVehicleRelatedInfoCueGroup
, and set ObjectType to CueGroup
and Object to ConVehicleRelatedInfoCueGroup
.ConFMSVehicleTabeListPage
form.ConVehicleRelatedInfoGroup
part, set the DataSource property to ConFMSVehicleTable
and the IsLinked property to Yes
.ConFMSVehicleTableListPage
and note that there is a link to the Vehicle services, with a quantity showing the number of service records. Clicking on this link will open the service list page showing records related with the vehicle. This is shown in the following screenshot:When you click on the Vehicle services cue, the data is automatically filtered based on the selected vehicle. This is done using a feature called a Dynalink. This is a mechanism that creates a dynamic link between the caller and the form that is opened.
To see this link, click on the new Vehicle services cue for a vehicle that has one or more services. Then right-click on this form and select Personalize.
The following screenshot shows the Query tab of this form. The Dynalink node does not filter on a specific value, but sets up a relation with the calling form's data source.
We can take this further and display a form part that will display a list of services, removing the need to actually navigate to the vehicle service table if the user simply wants to see the list.
The form part is simple, create a form for the form part as before. Name the form ConFMSVehServiceTableCuePart
, as we will use this only on a cue.
The form should have the table ConFMSVehServiceTable
as a data source. Then, add a grid based on the Overview field group. Set the grid's Width and Height properties to Column width
and Column height
respectively.
Remember these key points about form parts:
No
.Once you have created the form part and the associated menu item, use this in the PreviewPartReference property of the cue.
To test this, simply hover the mouse over the Vehicle services link, as shown here:
We can create a cue to any list page or form whose root data source has a relation with the list page's data source.
An important exception to this rule is where the target form clears dynamic links. Sometimes, we don't want the system to automatically filter the form based on the caller and in this case we can call a clearDynalinks
function on the data source object.
An example of this behavior is to be found in the TMSAppointment
form, which clears this link in init and can be found by navigating to Data Sources | TMSAppointment | Methods, as shown in the following code extract:
public void init() { QueryBuildDataSource qbds; super(); qbds = tmsAppointment_q.dataSourceTable( tableNum(TMSAppointment)); qbds.clearDynalinks(); //...
In order to create a cue to the appointment form, we have to modify this form to not to clear the dynamic links when it is called from our form. This is best done using element.args().dataset()
, as shown here:
public void init() { QueryBuildDataSource qbds; // Con 2014/09/07 – 6015-06 - modification by SB: // Do not clear dynaLinks if called from a // ConFMSVehicleTable record boolean conFMSDoNotClearDL; switch(element.args().dataset()) { case tableNum(ConFMSVehicleTable): conFMSDoNotClearDL = true; break; } // Con – 6015-06 end super(); qbds = tmsAppointment_q.dataSourceTable(tableNum(TMSAppointment)); // Con 2014/09/07 – 6015-06 - modification by SB: // Do not clear dynaLinks if called from a // ConFMSVehicleTable record // original code was to always qbds.clearDynalinks(); if(!conFMSDoNotClearDL) qbds.clearDynalinks(); // Con – 6015-06 end
The code to determine whether it should clear dynamic links should be in a method on the TMSAppointment
table to make it reusable. Also, to remove the number of custom lines of code in a standard method, it is placed inline here for clarity. In any case, this example has been included to show you how this particular issue could be solved. However, most of the time, cues will be related to information in a list page or details form and we will probably never come across this problem.
Now that the appointments form allows dynamic links, we can proceed to create our cue. The creation of this cue is the same as that of the service history cue, which is done with the following steps:
ConFMSAppointmentVehicleCue
query with a single data source named TMSAppointment
.ConFMSAppointmentVehicleCue
display menu item, setting Object to TMSAppointment
and the query to ConFMSAppointmentVehicleCue
.ConFMSAppointmentVehicleCue
, setting an appropriate label, and set MenuItemName to ConFMSAppointmentVehicleCue
.ConFMSVehicleRelatedInfoCueGroup
cue group.Feel free to write a preview part and attach this to the cue, as we did for the vehicle services cue.
3.145.96.86