There are several ways for communicating between objects during NAV processing.
The most widely used and simplest communication method is through data tables. For example, the table No. Series is the central control for all document numbers. Each object that assigns numbers to a document (for example, Order, Invoice, Shipment, and so on) uses Codeunit 396, NoSeriesManagement, to access the No. Series table for the next number to use, and then updates the No. Series table so that the next object needing to assign a number to the same type of document will have the updated information.
When an object calls a function in another object, information is generally passed through the calling and return parameters. The calling and return parameter specifications were defined when the function was originally developed. The generic syntax for a function call is as follows:
[ReturnValue := ] FunctionName ( [ Parameter1 ] [ ,Parameter2 ] ,…)
The rules for including or omitting the various optional fields are specific to the local variables defined for each individual function. As developers, when we design the function, we define the rules and thereby determine just how communications with the function will be handled. It is obviously important to define complete and consistent parameter passing rules, prior to beginning a development project.
Sometimes we need to create an object which in turn calls other objects. We may simply want to allow the user to be able to run a series of processes and reports but only enter the controlling parameters once. Our user interface object will be responsible for invoking the subordinate objects after having communicated setup and filter parameters.
There is a significant set of standard functions designed for various modes and circumstances of invoking other objects. Examples of these functions are SETTABLEVIEW, SETRECORD, and GETRECORD (there are others as well). There are also instances where we will need to build our own data passing function.
In order to properly manage these relatively complex processes, we need to be familiar with the various versions of RUN and RUNMODAL functions. We will also need to understand the meaning and effect of a single instance or multiple instances of an object. Briefly, key differences between invoking a page or report object from within another object via RUN versus RUNMODAL are as follows:
RUNwill clear the instance of the invoked object every time the object completes, which means that all of the internal variables are initialized. This clearing behavior does not apply to a codeunit object; state will be maintained across multiple calls toRUN.RUNMODALdoes not clear the instance of the invoked object, so internal global variables are not reinitialized each time the object is called. The object can be reinitialized by usingCLEAR(Object).RUNMODALdoes not allow any other object to be active in the same user session while it is running, whereasRUNallows another object instance to run in parallel with theRUNinitiated object instance.
Covering these topics in more detail is too advanced for this book, but once you have mastered the material covered here, you should study the information in the Developer and IT Pro Help relative to this topic. There is also a Pattern on this topic defined at:
https://community.dynamics.com/nav/w/designpatterns/108.posting-routine-select-behaviour.