7 Funktionen (functions)
Die Funktionen stellen das Interface zu der verwendeten Programmiersprache dar. Das Schlüsselwort hierzu ist function. Anschließend müssen der Funktionstyp und der Funktionsname angegeben werden. Im Sinne von Funktionsprototypen müssen statt der Funktionsargumente die Datentypen der Parameter angegeben werden. Bei dieser Definition müssen die Funktionen nach ihrem späteren Einsatz unterschieden werden.
Prinzipiell werden die folgenden Arten von Funktionen unterschieden:
-
Funktion, die aus den Regeln heraus aufgerufen wird
Dieser Funktionstyp kann bis zu 16 beliebige Parameter haben, die bei der Deklaration der Funktion entsprechend angegeben werden müssen.
-
Funktion, die direkt an einem Objekt hängt (Callback-Funktion)
Diese direkt bei der Definition des Objektes über .function angegebenen Funktionen müssen als Callback-Funktion definiert werden. Dabei definiert der ISA Dialog Manager, welche Parameter diese Funktion erhält. Sie dürfen daher bei der Deklaration nicht angegeben werden. Bei der Definition dieser Funktion wird weiterhin angegeben, bei welche Benutzerereignissen sie aufgerufen werden soll.
-
Funktion, die an einem Objekt Canvas hängt (Canvas-Funktion)
Da dieses Objekt in Bezug auf den IDM eine große Ausnahme darstellt und es auch von der Anwendung anders behandelt werden muss, gibt es hierfür einen eigenen Funktionstyp canvasfunc. Ihre Parameter werden ebenfalls vom ISA Dialog Manager fest definiert und dürfen bei der Deklaration nicht angegeben werden.
-
Diese Funktion kann im .datamodel-Attribut bei allen Objekten angegeben werden, die auch benutzerdefinierte Attribute unterstützen. Eine Datenfunktion kann dabei die Rolle eines Datenmodells (Model-Komponente) erfüllen um die Präsentationsobjekte mit Datenwerten zu versorgen. Die Parameter einer Datenfunktion sind vom ISA Dialog Manager fest definiert und können vom Benutzer nicht verändert werden.
-
Diese Funktion wird bei der Definition von Format-Ressourcen sowie bei editierbaren Texten und Tablefields im Attribut .formatfunc angegeben. Ihre Parameter werden vom ISA Dialog Manager definiert und dürfen bei der Deklaration nicht angegeben werden.
-
Nachlade-Funktion für Tablefields
Diese Funktion wird bei der Definition von Tablefields im Attribut .contentfunc angegeben. Ihre Parameter werden vom ISA Dialog Manager definiert und dürfen bei der Deklaration nicht angegeben werden.
Zulässige Sprachen sind:
Wird keine Sprache angegeben, wird C als Default genommen.
|
Datentyp |
Wertebereich |
|---|---|
|
Beliebiger undefinierter Datentyp; wird erst durch aktuelle Belegung definiert. |
|
|
Datentyp der Attribute im IDM. |
|
|
Boolescher Wert (true | false) |
|
|
Klasse eines Objekts, z.B. "window". |
|
|
IDM-Datentyp. |
|
|
Symbolische Konstante; Aufzählungstyp für verschiedene spezielle Attribute, z.B. "sel_row". |
|
|
Ereignisart, z.B. "select". |
|
|
Indexwert für 2-dimensionale Attribute [I,J]. |
|
|
Ganzzahl ("long integer"), z.B. 42. |
|
|
Methode, z.B. "delete". |
|
|
Objekt im Sinne des IDM (eigentliche Objekte, Ressourcen, Funktionen, Regeln…). |
|
|
Zeiger aus der Anwendung. |
|
|
Beliebig lange Zeichenkette (Null-terminiert), z.B. "Hallo". |
|
|
Datentyp mit keinem Wert. |
Anmerkung zum IDM für Windows
Der IDM-Datentyp integer entspricht dem Datentyp long in der C-Schnittstelle.
Der ISA Dialog Manager verwendet die Pascal-Calling-Convention als Default. Es ist ratsam, den Funktionsprototyp vom IDM schreiben zu lassen und einzubinden.
7.1 Funktion aus Regel
Diese Funktionen können explizit in den Regeln aufgerufen werden. Funktionen müssen einen der zulässigen Funktionstypen haben und sind mit maximal 16 Argumenten parametrisierbar. Der Datentyp eines jeden Argumentes kann innerhalb der Funktionsklammern angegeben werden; bei mehr als einem Argument sind die Datentypen durch Kommas zu trennen.
Syntax
{ export | reexport } function { <Sprache> } <Datentyp> <Funktionsname>
( { <Parameter> { , <Parameter> } } ) ;Sprache ::= c | cobol
Parameter ::= <Datentyp> { [ <Größe> ] } { <Parametername> { := <Standardwert> } } { input } { output }
Innerhalb dieser Deklaration der Funktionsparameter können die Parameter-Werte definiert werden. Dafür stehen drei Möglichkeiten zur Verfügung:
-
Soll ein Parameter nur als Eingabewert in eine Funktion dienen, so ist nach der Angabe des Datentyps das Schlüsselwort input optional, denn dieser Typ ist gleichzeitig der Default. Dieser Parameter kann durch diese Deklaration nur lesend in der Funktion verarbeitet werden.
-
Soll ein Parameter nur als Ausgabewert einer Funktion dienen, so muss nach der Definition des Datentyps das Schlüsselwort output angegeben werden. Dieses bedeutet, dass dieser Parameter in der Anwendung verändert werden muss und anschließend im IDM weiterbearbeitet werden kann.
-
Sowohl Eingabe- als auch Ausgabewert (input output)
Soll ein Parameter sowohl als Eingabewert in eine Funktion als auch als Ausgabewert dieser dienen, so müssen nach der Definition des Datentyps die Schlüsselworte input und output angegeben werden. Mit Hilfe dieser Deklaration hat man also die Möglichkeit, einen Attributwert in eine Funktion als Eingabeparameter zu geben, den Wert dort zu manipulieren und das Ergebnis dieser Manipulation wieder in dem entsprechenden Attribut anzuzeigen.
Parameter von Funktionen können auch mit Namen definiert werden, um z.B. besser erkennen zu können, wozu die einzelnen Parameter verwendet werden.
Beispiel
function c boolean ReadData(string Filename,
integer Index,
string Value output);
Es ist auch möglich, Defaultwerte für Parameter des Typs input zu definieren. Diese Parameter müssen dann beim Aufruf der Funktion nicht angegeben werden.
Zu beachten
Parameter mit Defaultwerten müssen am Ende der Parameterliste stehen.
Die Länge der Parameter kann auch an das System gegeben werden. Dies ist besonders relevant, wenn ein String (Zeichenkette) an die Anwendung übergeben werden soll, z.B. mit COBOL.
Die Größe muss in eckigen Klammern angegeben werden [<Größe>].
Zusätzlich können Parameter auch auf bestimmte Typen eingeschränkt werden, näheres siehe Kapitel „Gültigkeitsbereich zur besseren Typ-Prüfung“.
7.1.1 Alias-Name mit optionaler Codepage-Definition
Verfügbarkeit
Bei der Definition von Anwendungsfunktionen kann nach den Funktionsparametern das Schlüsselwort alias gefolgt von einem String angegeben werden.
Syntax
{ export | reexport } function <language> <return_data_type>
<function_identifier> ( { parameter [ , parameter ] } )
alias <alias_string> ; | <code_block>alias_string ::=
"<alias-name>{ ;<code_page> } | <code_page>"
code_page ::=
[CP=]<code_page_identifier>
Die Alias-Angabe dient dazu, bei einer dynamischen Anbindung den korrekten Funktionsnamen (also ohne Reglementierung wie beim Funktionsidentifikator) vorzugeben.
Im Alias-String kann außerdem eine funktionsspezifische Codepage für die String-Verarbeitung vorgegeben werden. Diese ist mit CP=
einzuleiten, direkt gefolgt vom Codepage-Bezeichner (analog zu den CP-Defines aus IDMuser.h, aber ohne-Präfix CP_
).
Ist zusätzlich ein Alias-Name definiert, muss die Codepage-Angabe mit Semikolon (;
) getrennt danach erfolgen.
Beispiele
function integer Atoi (string S) "myatoi;CP=utf8"; function string CurTime() "CP=utf16b";
7.1.2 Abfrage der Parameter einer Funktion zur Laufzeit
Die Funktion kann auch zur Laufzeit nach der Art seiner Parameter gefragt werden. Dazu müssen die Attribute .type für den Datentyp und .input für Inputwert bzw. .output für einen Ausgabewert jeweils mit dem Index des zu erfragenden Parameters angegeben werden. Wenn es sich bei dem Parameter um einen Parameter vom Typ string handelt, kann mit dem Attribut .size auf die Größe des Parameters zugegriffen werden.
Damit sind folgende Attribute für eine Funktion zulässig
|
Attribut |
Bedeutung |
|---|---|
|
.count |
Anzahl der Parameter |
|
.language |
Programmiersprache, in der die Funktion geschrieben werden soll |
|
.type |
Datentyp des Rückgabewerts der Funktion |
|
.input[I] |
Parameter I ist Eingabewert |
|
.output[I] |
Parameter I ist Ausgabewert |
|
.size[I] |
Größe des String-Parameters (nur relevant bei COBOL) |
|
.type[I] |
Datentyp des I-ten Parameters |
Beispiel
dialog Test
{
}
function void MeineTestFkt(integer A input output,
string[20] B output,
boolean C input,
pointer D input output);
on dialog start
{
variable integer I;
print MeineTestFkt.count;
print MeineTestFkt.type;
print MeineTestFkt.language;
for I := 1 to MeineTestFkt.count do
print MeineTestFkt.input[I];
print MeineTestFkt.output[I];
print MeineTestFkt.size[I];
print MeineTestFkt.type[I];
endfor
}
ergibt folgende Ausgabe im Tracefile
[XR] rule on dialog start (this=dialog Test)
4
void
"default"
true
true
0
integer
false
true
20
string
true
false
0
boolean
true
true
0
pointer
[XD] rule on dialog start
7.2 Callback-Funktion
Eine Callback-Funktion wird aufgerufen, wenn ein Objekt, an das diese Funktion gebunden ist, ein Ereignis erhält, das bei der Definition dieser Callback-Funktion angegeben wurde. Die Callback-Funktion wird vor der Abarbeitung der Ereignisregeln aufgerufen. Die entsprechenden Ereignisregeln werden nur abgearbeitet, wenn die Callback-Funktion den Wert true zurückliefert.
Syntax
{ export | reexport } function { <Sprache> } callback <Funktionsname> ( )
for <Ereignis> [ , <Ereignis> ] ;
Diese Funktionen können bei der Objektdefinition im Attribut .function angegeben werden. Bei der Definition der Funktion wird angegeben, bei welchen Benutzerereignissen – z.B. select, activate, deselect oder charinput – diese Funktion aufgerufen werden soll.
Die Parameter der Funktion sind vom IDM vorgegeben und können nicht verändert werden.
Beispiel
function callback ObjectCall () for close, move, activate;
window TestFenster
{
.function ObjectCall;
.xleft 17;
}
Diese Funktion wird dann aufgerufen, wenn der Benutzer das Fenster schließt, verschiebt oder aktiviert.
Siehe auch
Kapitel „Objektcallback-Funktionen“ im Handbuch „C-Schnittstelle - Grundlagen“
7.3 Canvas-Funktion
Canvas-Funktionen dienen zur Bearbeitung von speziellen Canvas-Ereignissen und erlauben das Darstellen beliebiger Grafiken innerhalb einer Canvas. Die jeweiligen Canvas-Ereignisse sowie die Art und Weise, wie Grafiken in der Canvas zur Anzeige gebracht werden, sind fenstersystemspezifisch.
Syntax
{ export | reexport } function { c } canvasfunc <Funktionsname> ( ) ;
Diese Funktionen können bei der Definition von Canvas-Objekten im Attribut .canvasfunc angegeben werden.
Die Parameter der Funktion sind vom IDM vorgegeben und können nicht verändert werden.
Beispiel
function canvasfunc HandleCanvas ();
window CanvasFenster
{
.xleft 17;
child canvas Dynamic
{
.canvasfunc HandleCanvas;
.width 100;
}
}
Siehe auch
Kapitel „Canvas-Funktionen“ im Handbuch „C-Schnittstelle - Grundlagen“
7.4 Datenfunktion
Eine Datenfunktion kann die Rolle eines Datenmodells (Model-Komponente) erfüllen um die Präsentationsobjekte mit Datenwerten zu versorgen. Aufgerufen wird die Funktion wenn eine Synchronisierung der Datenwerte erfolgen soll, also entweder um Datenwerte vom Datenmodell zu holen oder um sie zuzuweisen.
Syntax
{ export | reexport } function { <Sprache> } datafunc <Funktionsname> ( ) ;
Diese Funktionen können im .datamodel-Attribut bei allen Objekten angegeben werden, die auch benutzerdefinierte Attribute unterstützen.
Die Datenfunktion kann in C/C++ geschrieben werden, ab IDM-Version A.06.01.d wird mit der COBOL-Schnittstelle für Micro Focus Visual COBOL auch COBOL als Applikationssprache unterstützt.
Die Implementierung der Datenfunktion kann auf der DDM-Serverseite liegen.
Die Parameter der Funktion sind vom IDM vorgegeben und können nicht verändert werden.
Siehe auch
Kapitel „Datenfunktionen“ im Handbuch „C-Schnittstelle - Grundlagen“
Kapitel „Datenfunktionen“ im "Handbuch „COBOL-Schnittstelle“
Kapitel „Datenmodell“ im Handbuch „Programmiertechniken“
Attribute .dataget[attribute], .datamodel[attribute], .dataoptions[enum], .dataset[attribute]
7.5 Format-Funktion
Format-Funktionen dienen zur Formatierung von editierbaren Text- und Tablefieldinhalten.
Syntax
{ export | reexport } function formatfunc <Funktionsname> ( ) ;
Diese Funktionen können bei der Definition von Format-Ressourcen angegeben werden. Bei der Definition von editierbaren Texten und Tablefields können sie auch im Attribut .formatfunc angegeben werden.
Die Parameter der Funktion sind vom IDM vorgegeben und können nicht verändert werden.
Siehe auch
Kapitel „Format-Funktionen“ im Handbuch „C-Schnittstelle - Grundlagen“
7.6 Nachlade-Funktion
Nachlade-Funktionen dienen zum dynamischen Nachladen des Tablefieldinhalts und werden vom Dialog Manager aufgerufen, wenn in einem Tablefield vom Benutzer so gescrollt wird, dass der danach sichtbare Bereich Zeilen oder Spalten enthält, die keinen Inhalt haben. Die Nachlade-Funktion kann dann den fehlenden Inhalt in das Tablefield einfüllen und gegebenenfalls nicht mehr benötigte Inhalte außerhalb des sichtbaren Bereich löschen.
Syntax
{ export | reexport } function { <Sprache> } contentfunc <Funktionsname> ( ) ;
Diese Funktionen können bei der Definition von Tablefields im Attribut .contentfunc angegeben werden.
Die Parameter der Funktion sind vom IDM vorgegeben und können nicht verändert werden.
Siehe auch
Kapitel „Nachlade-Funktionen“ im Handbuch „C-Schnittstelle - Grundlagen“
7.7 Simulation von Funktionen
Funktionen, die nicht an den ISA Dialog Manager gebunden sind, können durch Regeln simuliert werden. Beim Entwickeln großer Anwendungen stehen dem Entwickler der graphischen Benutzeroberfläche oftmals nicht alle Funktionen zur Verfügung, die er zum Ablauf bzw. Simulation seiner Oberfläche benötigt. Dies behindert den Entwickler oder lässt ihn nur Teile seiner Anwendung testen. Um Dialoge unabhängig von den nicht vorhandenen Funktionen ablauffähig zu machen, können diese Funktionen durch Regeln simuliert werden. Funktionen, die an den Dialog Manager angebunden wurden, werden weiterhin wie gewohnt aufgerufen.
Folgende Funktionen können simuliert werden:
Bei der Definition der Funktion wird die Regel mitangegeben. Statt die Funktionsdefinition wie gewohnt mit einem Semikolon abzuschließen, wird eine geschweifte Klammer geöffnet, um danach die Simulationsregel zu definieren. Die Simulationsregel hat die gleichen Eigenschaften wie eine benannte Regel.
Beispiel einer Funktionsdefinition ohne Simulationsregel:
function c boolean CheckOnline();
Beispiel derselben Funktion mit Simulationsregel:
function c boolean CheckOnline()
{
return( true ); // always online simulation
}
Die Simulationsregeln lassen sich wie benannte Regeln benutzen. Sie besitzen die identischen Parameter wie die simulierte Funktion.
Beispiel
function c void ConvertDate(boolean CurrentDate input,
string Date input output)
{
// Date will be in format YYYYMMDD and we are to lazy to do
// this here, it will be sufficient for us to do this with
// two different dates
if ( CurrentDate ) then
Date := "11.11.2011"; // simulate always with this
// date as current
else
Date := "1.4.2010"; // no conversion supplied,
// this is sufficient
endif
}
function cobol boolean GetExchangeRate( string From input,
string To input, string ExchangeRate output)
{
case From
in "EUR":
case To
in "EUR": ExchangeRate := "1.000";
in "USD": ExchangeRate := "1.3249";
in "GBP": ExchangeRate := "0.8550";
... // many more currencies
endcase
in "USD":
case To
in "USD": ExchangeRate := "1.000";
in "EUR": ExchangeRate := "0.7548";
...
...
endcase
return (true);
}
record Currency
{
string Which;
string EUR;
string USD;
string CHF;
...
}
function cobol boolean GetCurrencyRates(record Currency
input output)
{
case Currency.Which
in "EUR":
Currency.EUR := "1.000";
Currency.USD := "1.3249";
...
in "USD":
...
}
Diese Simulation der Funktionen dürfte den meisten Anwendungen genügen. Eine vollständige Ersetzung der Funktionen ist in den allermeisten Fällen auch nicht nötig, da es reicht, den Dialogablauf sinnvoll zu steuern.
Der ISA Dialog Manager ermöglicht es dem Entwickler, Funktionen für Ereignisse direkt anzugeben. Diese werden beim Auftreten des angegebenen Ereignisses direkt aufgerufen. Bei diesen Callback-Funktionen können ebenfalls Simulationsfunktionen angegeben werden. Damit kann hier ebenfalls eine für die Dialogsimulation und Testverfahren vorteilhafte Funktionssimulation programmiert werden. Die simulierte Callback-Funktion hat dieselben Eigenschaften wie eine Ereignisregel. Die zugehörigen Ereignisregeln werden, falls vorhanden, immer nach der simulierten Callback-Funktion ausgeführt.
Beispiel
function callback PushbuttonSelect() for select, focus
{
if ( thisevent.event[select] ) then
// the simulation code for select
endif
if ( thisevent.event[focus] ) then
// the simulation code for focus
endif
}
default pushbutton
{
.function PushbuttonSelect;
}
on PUSHBUTTON select
{
// is also executed
}
Dadurch kann der Entwickler den Dialogablauf steuern und auf die Ereignisse reagieren ohne dass er die Ereignisregeln zusätzlich implementieren muss.
7.8 Funktionen in modularisierten Dialogen
Für die Benutzung von Funktionen in modularisierten Dialogen stehen die Attribute .application am import-Objekt sowie .masterapplication am modul- bzw. dialog-Objekt zur Verfügung . Damit können alle Funktionen eines Modules von„außen“ an eine spezielle Applikation gekoppelt werden. Die Vorgehensweisen für beide Varianten - für import und für use - sind im Kapitel „Programmiertechniken“/ „Modularisierung“ / „Objekt Application“ beschrieben.
Support