Consultor Eletrônico

Fast record links between objects on two smartwindows

How to create a fast record-link between a record-source
and a record target on two seperate windows.


In many cases during the development of a new application you may
need the possability to lay record-links between (record-handling)
objects on two seperate windows. There are many ways to implement
such behaviour, this knowledgebase descibes the building of such a
link and in short it describes the advantages and disadvantages
of the methods used.

The first thing to think about before finding a way of linking is how
to create the two seperate (smart)windows. These windows can be run
seperately or depedent of each other only. In most cases however they
are written the last way. This means that they are dependent of each
other by means of record source and target. Thus: The windows need
each others components and info to run correctly.

If it cannot be done elseway as the second window needs e.g. a
calculation done in the first window, then so be it. But if the
second window can be run alone, it gives the opportunity to create
entrypoints to that window from many different menu's or windows.
This can even be extended by making the window aware whether there
is or is not an external record source to link to, so it can be
used in even more situations.

It is important to state this because many programmers do re-use
smartobjects such as viewers and queries, but do not re-use
the smartwindows ! That's a missed chance, as the windows are easily
made reusable. Development should consider these opportunities !

Now that there are two windows, the next step is the linking setup:
At first, the first window needs to know the handle of the second.

The simplest way is to place the second window on a page of the first.
Then the linking is handled by the paging functionality. Problem is:

1. On page 0 they are always shown when starting up.
2. You may get problems with the links that are automatically enabled
and or disabled by paging when on page 1 or higher.
3. At last you have to be carefull when also using a smartfolder
which also handles paging.

Big advantages: It's simple and it's fast. Even a novice programmer
can build it within a couple of minutes.

Generally, the other way is to start up the second window from
out of the first or from some sort of main window (desktop or shell).
The second window should always be run persistent as we need access
to it's internal procedures/coding blocks. In the programming books
most examples show that a record link should be build with the use of
the this-procedure handle in each window. This is rubbish, it works
allright, but why not lay it directly between the record-source and
target ? As this is more complicated, the example below will show it
in detail.

As an example here , two windows are used:
a. (the browse-window)
a window with a button and a smartbowser (e.g. customer.cust-num
and name) for fast record searching.
b. (the detail-window)
a window with a smartviewer for customers,
a smartquery for customers (so it can run independetly)
a navigation panel on the query
a standard transaction panel for the smartviewer.


In the definitions section of the first window there is the entry:

DEFINE VARIABLE window2 AS HANDLE NO-UNDO.

There is a CHOOSE trigger on the button which starts up
the second window:

ON CHOOSE OF BUTTON-1
DO:
IF NOT VALID-HANDLE(window2) THEN
DO:
RUN w-win2.w PERSISTENT SET window2.
RUN DISPATCH IN window2 ('initialize':u). /* Make it visible ! */

DEFINE VARIABLE lst-objects AS CHAR NO-UNDO.
DEFINE VARIABLE i AS INT NO-UNDO.
DEFINE VARIABLE h_viewer AS HANDLE NO-UNDO.
DEFINE VARIABLE h_query AS HANDLE NO-UNDO.

RUN get-link-handle IN adm-broker-hdl
(INPUT window2,
INPUT "CONTAINER-TARGET":U, /* get all objects on window */
OUTPUT lst-objects).

DO i = 1 TO NUM-ENTRIES(lst-objects):
RUN get-attribute IN WIDGET-HANDLE(ENTRY(i,lst-objects))
(INPUT "TYPE":U).
IF RETURN-VALUE = "Smartviewer":U THEN /* make selection .. */
DO:
DEF VAR lc-query AS CHAR NO-UNDO.

h_viewer = WIDGET-HANDLE(ENTRY(i,lst-objects)).
RUN get-link-handle IN adm-broker-hdl
(h_viewer,"RECORD-SOURCE":U, OUTPUT lc-query).
h_query = WIDGET-HANDLE(lc-query).
RUN remove-link IN adm-broker-hdl /* remove the old */
(h_query,
"RECORD":U,
h_viewer).

RUN add-link IN adm-broker-hdl /* point to new source */
(h_b-cust, /* insert known browserobject */
"RECORD":U,
h_viewer).
END.
END.
END.
END.

Although this gives a small impression of what can be done, it can
be extended easily. For instance the h_b-cust can be found using
the broker, to make the code more portable.

Also it might be an idea to create a maintenance programm in which
you can set where to create a link to based on some conditions.
The only limit is the programmer's fantasy.