Dialogs

User interface forms

Contains controls methods events
Convert: Binary data is built (dialog info, size,
controls, control positions, functions, events),
Language independent
Save: Binary data and language depentend dialog
texts are written to .dlg files on the server.
When dialog opened, system reads the .dlg files.
When running dialogs, System DOES NOT
access development tables. (ProdDB, DevDB)
 Dialogs
● Events: Automatically called methods
– BEFORE, AFTER, ONSHOW, TRANSCALLED,
ONTIMER, BEFOREEXTENSION
● BEFORE:First event on dialog open, fired after controls
defined (dialog is not visible), AFTER: Called after
BEFORE, dialog still not visible, ONSHOW: dialog is
visible
– Manual calling possible: THIS.AFTER() not a good
practice, though
● Controls
– Textfield: Many subtypes (DATE, FILECHOOSER,
HTML, Editor..)
● Note: Dialoog (UI layer)
● Note: BAD PRACTICE THIS.AFTER()
● Note: PRODDB (data), DEVDB (sources)
 Dialogs
● Tab Dialogs
– SubDialog Before/After once:
– SubDialog LinkBefore/After always
– Order:
●
 Dialogs
● Main.BEFORE
● Main.AFTER
● Sub1.BeforeLink
● Sub1.BEFORE
● Sub1.AFTER
● Sub1.AfterLink
● Sub2.BeforeLink
● Sub2.BEFORE
● Sub2.AFTER
● Sub2.AfterLink
● Sub1.BeforeLink
● Sub1.AfterLink
 Dialogs
● Switching
– Open a transaction (defined start dialog)
– CALL DIALOG ..
● CALL DIALOG dialog
● CALL DIALOG dialog WITH LOCATION/SIZE (popup)

Call a dialogs stops execution at that point and returns until

close of dialog (SHUTDOWN)
● SHUTDOWN: Closes last opened dialog (think as a stack.) If
last dialog of transaction closed, transaction is closed auto.
● Dialogs: Variables accessible within dialogs of transaction
(scope) When dialog closed, global variables still exist.
 Dialog Close & Scope
● After a dialog is closes, global variables that are
defined by closed dialog are not removed from
the memory so they are still accessible.
● So programmers must consider symbol names
and types on closed dialogs when defining new
variables and controls.
 Transactions
● Business level application
● Transactions are only structure able to execute
TROIA code
● Start dialog
● Define: SYST00 (Name, module, start dialog)
● Largest scope
● Calling:
– User menu, shortcut, quick launch
– CALL TRANASACTION
 Transactions
● CALL TRANSACTION tranname /
CALL TRANSACTION tranname (P1,P2..)
– Does not block caller / output not possible
– Does not block caller / output not possible
● CALL TRANSACTION tranname (P1,P2..) WITH WAIT /
CALL TRANSACTION tranname (P1,P2..) WITH WAIT
(O1,O2..)
– Does block caller
– Puts values into O1, O2
– Resume caller when opened transaction is closed
– WITH WAIT: user can not switch to caller until opened is
closed
 Transaction
● CALL TRANSCATION IN SERVER
– Simulate client action without gui
– Calls transaction, opens start dialog, runs code and
closes
– No interaction from user
● INPUT PARAMETERS
– Defined as global variables
– If input parameters are specified, TRANSCALLED
is auto. Called after AFTER event of the dialog
– If no input parameter: TRANSCALLED not invoked
● CALL TRANSACTION (PARAM1..)
– Not meaningful calling with (6,..)
– PARAM1 is accessible in the called transaction with
value
– No global scope between transactions
 Transactions
● Planned/Scheduled task
● Transactions are only structure able to execute
TROIA code
● Batch transaction/client concept
– SYST00: Batch code tab: If transaction is run as
batch, start dialog run, additionally runs batch code.
– Client based batch, user interface visible
– Console application (Server Admin Utility)
– Scheduing done by operating system (windows task
scheduler, linux crontab)
– No embedded scheduling tools