Tuesday, 8 July 2014

Session is started with the context of the Parent

Introduction

Sessions started from the menu are not started with a certain context. However, many sessions can be started from another session via the session menu, a button, etc. In that case, the session is started with the context of the parent and should show the proper data. This document explains what is needed in your program script in order to handle this behavior properly.

Situation


Suppose that table 'Items' (tcibd001) contains some fields and two indexes. The first index is the primary key and exists of field 'Item' (tcibd001.item). The second index consists of fields 'Item Group' (tcibd001.citg) and 'Item' (tcibd001.item). Index 1 and index 2 are available in the 'Sort by' option of the session 'Items'. Suppose you have started the session 'Items'. You have changed the sort by to index two and have closed the session. The next time you start this session again, it should start with index 2.

Note: Currently sessions are not always starting with the last-used index, but with index 1. This is an error and has been solved in Tools.

Suppose you start the session 'Items' from the menu of another session, so with context. In many cases, the zoom.from.all or init.group section is used to import some data from the parent session. See the following code for an example. Note that this example is made as easy as possible, without the usage of the UI-template.
 
 
group.1:
init.group:
import("tcibd001.item", "imported.item")
if not isspace(imported.item) then
tcibd001.item = imported.item
ignore.first.event = true
execute(find.data)
endif


Find below the content of the item table in our example, ordered by index 2.

ItemItem group
APPLE FRUIT
BANANA FRUIT
ORANGE FRUIT
CHISEL TOOLS
DRILL TOOLS
HAMMER TOOLS
SAW TOOLS
SCREWDRIVER TOOLS

Problem Description


Suppose that the selected item code in a certain parent session is 'HAMMER' which belongs to item group 'TOOLS'. What happens if we start session 'Items' from the parent sessions? It will use the imported item to show the proper object. The choice find.data will retrieve the data from the database. To do so, the current active index is used. In our example index 2 ('Item Group', 'Item') is used. The value of tcibd001.item (HAMMER) has been imported and is available. But, the value of tcibd001.citg is empty. So, choice find.data obviously returns item APPLE as the first record to be displayed. And this is wrong.

Summarized: A session, started from a parent, will not show the proper data if one of the fields in the active key is unknown.

Solution


The solution for this problem is very easy. Make sure that all fields of the active key are known. This can be done in different ways. The preferred and most robust way is to read this data with a simple select. The solution in our example would be:

group.1:
init.group:
import("tcibd001.item", "imported.item")
if not isspace(imported.item) then
if curr.key <> 1 then
select tcibd001.*
from tcibd001
where tcibd001._index1 = {:imported.item} | sometimes you need: "where tcibd001._index1 => {:imported.item}"
as set with 1 rows
selectdo
endselect
else
tcibd001.item = imported.item
endif
ignore.first.event = true
execute(find.data)
endif


Notes

1.    If you start a session from a parent and a certain key is required from a functionality perspective, you need to set the whished index in your program logic.

2.    In most cases a standard read function is available. In our example the select on tcibd001 should be replaced by tcibd.dll0001.read.item(imported.item).

3.    Reading all fields ensures that all fields of all indexes are filled.

4.    Make sure this solution will not conflict if you use function to.key() in your script.

5.    In our example index 1 is imported. If you import another index, you need to change the code accordingly.

No comments:

Post a Comment