Naja, ganz so einfach ist das leider nicht, da bei SFLDROP das Programm normalerweise nicht aktiviert wird.
Man muss die Steuerung also selbst übernehmen.
Die Schlüsselworte SFLDROP/SFLFOLD müssen mit Bezugszahl definiert werden, damit man sie gezielt ansteuern kann.
Eine 1-stellige Programmübergabe-Variable mit SFLMODE liefert den aktuellen Stand (gefaltet, geöffnet).
Mit SFLCSSRRN bekommt man die aktuelle Satznummer des Cursors.
Die Funktionstaste für SFLDROP muss vom Programm ausgewertet werden (also keine Zuordnung der Taste).
Drückt der Anwender nun die Taste, wird über SFLMODE festgestellt, wie der Modus nun zu ändern ist.
Per SFLRCDNBR kann mit Ansteuerung der Bezugszahl für SFLDROP/SFLFOLD die Anzeige wiederhergestellt werden.
Bleibt nur noch das Problem der Cursorpositionierung.
Default steht der Cursor auf dem 1. Feld des SFL-Satzes. Möchte man nun auf einem bestimmten Feld positionieren, kann man das mit DSPATR(PC) erreichen, aber:
Man bedenke, dass nur der 1. DSPATR(PC) wirkt. Wenn also mehrere SFL-Sätze noch das DSPATR(PC) enthalten, wird ggf. auf dem falschen Satz positioniert, was insbesonders beim Blättern stört (der Cursor springt durch die Gegend).
Lösung:
Per Schleife alle SFL-Sätze bearbeiten und das DSPATR(PC) zurücksetzen (Bezugszahl) und gezielt für den ausgewählten Satz wieder setzen.
Allerdings: Blättert der Benutzer nun, steht der Cursor ggf. auf der falschen Stelle (er bleibt ja erstmal stehen). Der Benutzer versetzt den Cursor und blättert wieder zu dem Satz mit DSPATR(PC) zurück/vor und schon steht der Cursor wieder auf dem Feld.
Auch hier hilft nur, das Blättern selbst in die Hand zu nehmen und das DSPATR(PC) zurückzusetzen (unter Beachtung des akt. SFLMODE und damit der Anzahl sichtbarer Sätze pro Seite).

Die andere Alternative ist hier dann CSRPOS, was allerdings bedeutet, dass die Cursorpositionen der Felder im Programm zu jeder Zeit bekannt sein müssen und das Setzen des Cursors IMMER damit erfolgen muss (bezogen auf das Satzformat).