Calling procedures

Calling procedures

Introduction

A procedure defined in a module A can be called
1. in this module (trivial case)
2. in all modules derived from A (inheritance)
3. in any module if module A makes the procedure accessible for external call (A becomes provider)

Case 1 and 2 correspond exactly to the method call in many other programming languages.
Case 3 is available from DLL version 4.5.2.174605.
The relationship between the caller (module C in the example) and the called procedure (here in module A) is indirect; an identifier (provider tag) is placed in between.
InstantView® creates the connection dynamically at runtime.
There is a loose coupling between calling module (C) and providing module (A).
The exported code and the program code of the callers can be developed independently of each other.

The calling module never knows the exporting module, because this module can change:
- Further development of the InstantView® program code in general
- Inserting customer-specific derivatives

Provider tags must be declared in the calling module (Statement Provider).
A module describes the export via a provider tag in the external statement.
For a call provider_tag::Procedure there must be exactly one provider in the project. Otherwise an error message appears.

Procedure export / import and inheritance

Export from a base module refers only to this one. Procedures redefined in derived modules are not visible. InstantView® internally creates a derived module without further content.
Example:

SetFormat and call(Procedure) in access expressions

In this case, the time of calling SetFormat and that of calling a procedure defined in the format description do not match.
In which module is the Procedure Foo defined, if an instruction like

[ "CX_ITEM::pattern.call(Foo)" . . . ] SetFormat

is carried out?
The following rule determines this:

a) in the module where the target Windows object(ListView, Tree, Combobox) is defined This always applies before DLL version 4.5.2.174605. After that always if case b) is not applicable.
b) SetFormat is executed in a procedure called from another module with a provider tag: Then it is assumed that all procedures to be called via call(Procedure) are also defined in this module.

Example:

When displaying the data, the ListView will call different procedures for column 1 and 2.
The assumption behind this specification is that call(Procedure) in a SetFormat statement refers to the module where SetFormat is currently executed.
If this does not apply, SendMsg can be used:

When displaying the data, the ListView will call the same procedure from module A for column 1 and 2.