Det2 detail is a section with the name and signature of user issuing an invoice.
I generate pdf from the report and insert an electronic signature into it.
The signature widget must hit into det2 exactly.
It can be a big PITB, if you don’t know the Y position of the last printed non-absolute detail. So even if you use ABSOLUTE on the one detail, you still have the same issue.
I wrote a report flow class to track the positions so I’d know where to place absolute details or whether the next PRINT() will flow to the next page, but it’s not mine to share.
If all of the details are of a fixed height, then it’s not so difficult. Otherwise, you need to loop through the controls of the detail to determine what the next height (including resizable controls, like TEXT) will be then add that to the tally. A lot of time and cursing was involved before I got it working correctly, btw.
The REPORT Engine is designed for you to NOT know the position of details or page breaks so it can do Widow/ Orphan control and other features to flow details nicely.
It is possible to do manual page breaking so that you can know the YPos of a Detail because you have counted all the Heights of what you have printed and done your own ENDPAGE(). You must NOT use any of the features @MarkGoldberg described, like WITHPRIOR, otherwise the Report Engine will be doing things you don’t know about,
One other thing you must do is set the Prop:MaxHeight=Prop:Height for all DETAILs or the Engine will expand their height a little sometimes. You also want your Band Area Height (the Report AT(,H)) to be bigger than you need so the Engine does not hit overflow. That way if you mess up you’ll see your details print in the Footer area.
My GIST below has a Template to do the MaxHeight plus place the Band Height into a variable for use in counting. There is also a simple ManRpt Manual Report class to assist.
The ONLY way to know for certain is to use fixed height details and subtract the height of each printed detail from the report AT() which defines the region usable for details and group headers and footers. It’s like we did in DOS, you had to count the lines to know when a page was going to overflow.
The only other way to know a page overflow is happening is to force it using ENDPAGE() otherwise with orphan and widow control you can have multiple “pages” in memory waiting for your conditions to be met for both orphan and widow.
Use fixed height details and keep tabs on how much of the report AT() has been used before each detail is printed, then you’ll know where it is, again, assuming no orphan or widow control.