This works as expected to allow the RPG program to specify subfile positioning by the desired relative record number. However, I have a couple of co-workers who are trying to do the same thing from scratch (i.e., completely from within the Designer) but their RPG programs cannot cause the subfile to be positioned at all. Is there something we are missing? ...or is this any issue with the Designer? (Sorry to post here, if so.)
Also, we tried adding the SFLRCDNBR(*TOP) keyword to the binding (though this doesn't seem the correct thing to do, either) and that won't even compile.
Yes, we did that and it compiles. But, that is apparently not enough to give the RPG program the ability to control subfile positioning. Only the screens we've converted are working. The screens we've developed from scratch are not working. When I compare the generated DDS source there is a big difference between the two source files. The converted source mentions the bound field five times. The from-scratch source mentions the bound field only two times.
In the converted version, it probably also created a hidden element for this field. It does this for all hidden fields. So, that's why you see more occurrences. But the extra hidden element shouldn't affect the functionality.
I just created a simple example from scratch using "subfile record number" and "position at top" and it seems to work just fine. So it's kind of strange that it's not working for you.
OK, I've now had a chance now to create my own subfile grid from scratch and the subfile positioning is working just like the ones which were converted from green-screen. So... I'll get back with the programmer here that originally reported this problem to me and see what is the real issue. Thanks.
Turns out that the problem was as a result of my cohorts turning on the "sortable columns" option and also specifying an "initial sort column". The result is that the "subfile record number" specification is ignored or lost when PUI performs the initial sort in the browser at render time.