D365 F&O Go to Main table EDT Relations / FormRef / JumpRef() method

 

 

There is 3 way to achieve GotoMaintable concept in D365

1.     EDT Relations

If you use an EDT in tables which have relation with some other table fileds, that time you can able to navigate the main table or main form.

For example, the CustAccount EDT

Expand the ‘Table Relations‘ node for EDT. The properties that the Table property is set to ‘CustTable‘.

2.     FormRef property in Table

FormRef Property:

Select the Table and go to properties and select the required form in the FormRef property.

3.     using JumpRef method

 

JumpRef method:

If you are not having that option, simply write a override the JumpRef method in a field of DataSource or in a Form Control. Here i show you a sample jumpRef method code:

 

In the name itself u can understand that “jumRef” means to “Jumping to the referenced table” of the particular id.

the below is code to jump to referenced purchase order when click purch id.

public void jumpRef()

{

PurchTable purch;

Args args;

MenuFunction menuFunction;

Common rec;

;

rec=PurchTable::find(this.valueStr());

args = new Args();

//args.lookupRecord (PurchTable::find(this.valueStr()));

args.record(rec);

args.caller(element);

// Create a new MenuFunction that launches the Reasons Menu Item

menuFunction = new MenuFunction(menuitemdisplaystr(PurchTable),MenuItemType::Display);

menuFunction.run(args);

}

 

Another Example Ref 

To see the overridden D365 JumpRef method, first search for SalesTable in the Application Explorer, in Visual Studio. Right click on the SalesTable form, and select ‘open designer‘.

To better understand, let us start with an example. In D365, navigate to Accounts Receivable>Orders>All sales orders. Next, click on a sales ID to go into the sales order details form. Then, select or a create a sales line. Expand the Line details fast tab. Finally, click on Delivery tab. Locate the field ‘Shipping carrier’.

This form control has an overridden D365 jumpRef method. When this field is populated, the value is blue, and can be clicked on. Or, the user can right click on the field and select ‘View details’.

This takes the user to the Shipping carriers form.

Now that you have seen the functionality from the from end form, let us look at the code in Visual Studio.

Overriding The JumpRef Method

To see the overridden D365 JumpRef method, first search for SalesTable in the Application Explorer, in Visual Studio. Right click on the SalesTable form, and select ‘open designer‘.

Next, we need to locate the ‘Shipping carrier’ form control in the form. The easiest way to do this is right-click on the control’s label in the browser. A pop-up will show us the name of the control. In this example, we can see that it is named ‘TMSCarrierInfo_CarrierCode‘.

Now that we know the name of the control, go back to Visual Studio, and enter the control name into the top bar of the form designer. Then, push Enter. The system will change the Design window to only show the form control, and its parent nodes.

 

 

Now that we have located the control in the form, expand the control node, and Methods node. Notice, the D365 jumpRef method is shown.

This means that the jumpRef method has been overridden. When it is not shown, the functionality is still there. It just means that the method will work in its default way.

Next, double click on the jumpRef method node to open up this method in a code editor.

 

To continue with our example, right-click on the method that is called within the overridden jumpRef method. Then, select ‘Go to definition‘. This will take you to the code where this method is defined. Also notice, that the code ‘this.valueStr()’ takes the current value in this form control, and passes it to the calling method.

To explain, the code instantiates a class named ‘Args’. This is a generic class that will be used to pass a record to the calling form, so that the calling form can filter on it.

First, the code uses the passed in _carrierCode variable to find a record in the TMSCarrier table.

Secondly, the code calls the ‘record‘ and ‘lookupRecord‘ methods on the Args class, passing in the TMSCarrier table buffer variable. If the record passed in is the same table as the main data source on the calling form, then the system will automatically filter the data source to that record. Very cool!

Thirdly, the code instantiates the MenuFunction class, and passes in the name of the Menu Item to call. In this example, there exists a display menu item name TMSCarrier.

Finally, the code calls the ‘run’ method on the MenuFunction class, and passes the args variable as a parameter. This tells the system to run the form connected to that Menu Item. Again, by passing in the args variable with the ‘record’ set, the calling form will be filtered to that record, as long as the data source and the record use the same table.

 

 

Why Override The JumpRef?

Now, you may be asking yourself: Why override the D365 JumpRef method? Why not use table relations? A developer should be using table relations when possible. However, there are a few scenarios where this may not be possible or work the way the developer needs it to.

No Table Relation Setup

First, in the above example, there is no relation on the SalesTable table between it and the TMSCarrier table. And therefore, the default functionality would be to now allow the user to click ‘View details’ on this field. Sometimes, adding a table relation can cause problems. However, if the ‘view details’ functionality is still desired, a developer can override the jumpRef method to make this functionality work.

There Is No Related Form

Secondly, there are times when a table relation exists, but there is no related form. In this scenario, clicking ‘view details’ would not do anything. So the jumpRef needs to be disabled to make sure the system does not try to navigate to a form that does not exist.

 Ref