From 6f7fb99c49c9db88c437efff900df52e9c77ceab Mon Sep 17 00:00:00 2001
From: Kristof Szabados <Kristof.Szabados@ericsson.com>
Date: Mon, 13 May 2019 13:19:15 +0200
Subject: [PATCH] some references fixed.
Signed-off-by: Kristof Szabados <Kristof.Szabados@ericsson.com>
---
usrguide/java_referenceguide/11-encoding_and_decoding.adoc | 2 +-
usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc | 2 +-
usrguide/java_referenceguide/9-test_ports.adoc | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/usrguide/java_referenceguide/11-encoding_and_decoding.adoc b/usrguide/java_referenceguide/11-encoding_and_decoding.adoc
index efc171ec7..5f6dca60c 100644
--- a/usrguide/java_referenceguide/11-encoding_and_decoding.adoc
+++ b/usrguide/java_referenceguide/11-encoding_and_decoding.adoc
@@ -3,7 +3,7 @@
:table-number: 2
:toc:
-TITAN is equipped with several standard encoding/decoding mechanisms. A part of these functions reside in the core library, but the type-dependent part must be generated by the Java code generator. In order to reduce the code size and compilation time, the code generation for encoding functions (separately for different encoders) can be switched off if they are not needed. FIXME link a beallitasokra.
+TITAN is equipped with several standard encoding/decoding mechanisms. A part of these functions reside in the core library, but the type-dependent part must be generated by the Java code generator. In order to reduce the code size and compilation time, the code generation for encoding functions (separately for different encoders) can be switched off if they are not needed as described in <<5-compiling_ttcn3_and_asn1_modules.adoc #build-options, Build Options>>.
To make it easier to use the encoding features, a unified common API was developed. With help of this API the behaviour of the test executor in different error situations can be set during coding. There is also a common buffer class. The details of the above mentioned API as well as the specific features of the certain encoders are explained in the following sections.
diff --git a/usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc b/usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc
index 9b80cfe05..15e7aa8ad 100644
--- a/usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc
+++ b/usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc
@@ -93,7 +93,7 @@ public class MyModule_externalfunctions {
----
-Both pre-defined and user-defined TTCN–3 data types can be used as parameters and/or return types of the Java functions. The detailed description of the equivalent Java classes as well as the name mapping rules are described in chapter FIXME correct<<4-encoding_and_decoding.adoc#xml-encoding-xer,XML Encoding (XER)>>.
+Both pre-defined and user-defined TTCN–3 data types can be used as parameters and/or return types of the Java functions. The detailed description of the equivalent Java classes as well as the name mapping rules are described in chapter <<12-mapping_ttcn3_data_types_to_java_constructs.adoc #mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
Using templates as formal parameters in external functions is possible, but not recommended because the API of the classes realizing templates is not documented and subject to change without notice.
diff --git a/usrguide/java_referenceguide/9-test_ports.adoc b/usrguide/java_referenceguide/9-test_ports.adoc
index e07d29303..da930edf9 100644
--- a/usrguide/java_referenceguide/9-test_ports.adoc
+++ b/usrguide/java_referenceguide/9-test_ports.adoc
@@ -305,7 +305,7 @@ Outgoing operations are `send` (specific to message based ports); `call`, `reply
The Test Port class has an overloaded function called `outgoing_send` for each outgoing message type. This function will be called when a message is sent on the port and it should be routed to the system (that is, SUT) according to the addressing semanticsfootnote:[That is, the port has exactly one mapping and either the port has no connections or the message is explicitly addressed by a `send (…) to system` statement.] of TTCN–3. The messages (implicitly or explicitly) addressed to other test components are handled inside the test executor; the Test Ports have nothing to do with them. The function `outgoing_send` will be also called if the port has neither connections nor mappings, but a message is sent on it.
-The only parameter of `outgoing_send` contains a read-only reference to the message in the internal data representation format of the test executor. The access methods for internal data types are described in FIXME "this reference needs to be fixed later"<<4-encoding_and_decoding.adoc#xml-encoding-xer, XML Encoding (XER)>>. The test port writer should encode and send the message towards SUT. For information on how to use the standard encoding functions like RAW, please consult the earlier chapters of this document. Sending a message on a not started port causes a dynamic test case error. In this case `outgoing_send` will not be called.
+The only parameter of `outgoing_send` contains a read-only reference to the message in the internal data representation format of the test executor. The access methods for internal data types are described in <<12-mapping_ttcn3_data_types_to_java_constructs.adoc #predefined-ttcn-3-data-types, Predefined TTCN–3 Data Types>>. The test port writer should encode and send the message towards SUT. For information on how to use the standard encoding functions like RAW, please consult the earlier chapters of this document. Sending a message on a not started port causes a dynamic test case error. In this case `outgoing_send` will not be called.
==== Call, Reply and Raise Functions
@@ -366,7 +366,7 @@ protected void incoming_message(final TitanCharString incoming_par);
==== Receiving calls, replies and exceptions
-Receiving operations on procedure based ports is similar to receiving messages on message based ports. The difference is that there are different overloaded incoming functions for call, reply and raise operations called `incoming_call`, `incoming_reply` and `incoming_exception`, respectively. The event handler (when called) must recognize the type of operation on receiving and call one of these functions accordingly with one of the internal representations of the signature (see FIXME reference <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc #additional-non-standard-functions, Additional Non-Standard Functions>>).
+Receiving operations on procedure based ports is similar to receiving messages on message based ports. The difference is that there are different overloaded incoming functions for call, reply and raise operations called `incoming_call`, `incoming_reply` and `incoming_exception`, respectively. The event handler (when called) must recognize the type of operation on receiving and call one of these functions accordingly with one of the internal representations of the signature (see <<12-mapping_ttcn3_data_types_to_java_constructs.adoc #additional-non-standard-functions, Additional Non-Standard Functions>>).
In the examplefootnote:[In the example the signatures were defined in a different TTCN–3 module named MyModule2, as a consequence all types defined in that module must be prefixed with the Java name of that module and its class be imported.] the class `MyProcedurePort_BASE` has the following member functions for incoming operations:
[source]
--
GitLab