|
| Some R/3 screens contain one or more scrollable areas. There is a vertical or horizontal scroll bar on one edge of the area, and the user can scroll through this part of the screen.
Example (Transaction VD03):
It is possible to handle these areas with GuiXT in the usual manner, for example to rename and delete fields. But special care has to be taken when you create new elements within such an area. Let us assume that you want to display a small additional box containing a couple of pushbuttons:
Your script coding might look as follows: if Q[Page=Address] The problem now is that GuiXT uses the absolute coordinates that you specified, but does not assign your new elements to the right scrollable area, thus causing repainting problems during and after scrolling. For example, the screen might look like this:
There is a way to ensure that your new elements become part of the scrollable area: use the Offset command. When you specify an Offset referencing an existing screen element, GuiXT not only takes the coordinates of this element as new base, but also assumes that further new elements should become part of the same screen area as the referenced element. In our example, you could use the Preview pushbutton: if Q[Page=Address] Your new elements are then correctly shown during and after all scrolling operations. Instead of using the Offset command, you could also use relative coordinates in each line, i.e. if Q[Page=Address] To clarify the difference again, with a simple example, look at the following scripts (same screen): A: Text (20,90) “xxxxxxxxxx”
B: Text P[Preview]+(16,85) “xxxxxxxxxx” Since P[Preview] is on (4,5), the absolute text coordinates are the same. But the assigned screen areas are different:
In case A the text is displayed within the non-scrollable main area of the screen.
In case B it is initially not shown at all, but…
…when the user scrolls down, the text becomes visible.
|
