Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Smart form page protection at runtime

Former Member
0 Kudos

Hello All,

I believe I have a bit special requirement to achieve in this scenario. Please help me if there is some good way to do it.

I have a smart form structure as shown below. Now there are certain elements ( highlighted in the image) which should display in one single page.

In other words, they should never display separately in different pages. If there is not much space available in current page,

a page break should happen and all of these elements should display in the next page.

The row width( MPO_DATA_ROW1 ) is not constant. Because it has a loop inside and hence the width will vary.

I want atleast the first row from DATA_TABLE1 to display with TEXT9 and HEADER_TABLE1.

Sample Output of such elements together:

My concern is:

1. How will I know how much space is left on the current page, at runtime. So that I can judge and do a page break ( Using command ) .

2. I have to determine how much space will these elements together take, beforehand. And due to the inner loops their width is not fixed.

I am aware of Folder concept and page protection. But I believe I cannot apply those here.

Kindly suggest some way!

Thanks,

Barkha

1 ACCEPTED SOLUTION

Private_Member_7726
Active Contributor
0 Kudos

Hi,


I'm having hard time grasping where exactly is %TEXT9 in the sample output, but could it not somehow go in under the Table header, perferably in the %ROW2 as well? Ok, I got it, thinking of a way to combine those... Single table row can be protected (but then you probably already were aware of that).

Edit in 2: Yes, one can protect more than one row type under table header using folder. The only problem is: no matter what I try, at implicit page-break the composer looses the header contents... Seems to be a wierd bug of some kind, related to footer, because sometimes parts of contents appear even outside main window


1. How will I know how much space is left on the current page, at runtime. So that I can judge and do a page break ( Using command ) .


I take it you mean in the MAIN window, right? Only via an implicit enhancement in SF composer runtime somewhere in SAPLSTXBC that would allow you to access ft-rem_height (remaining height in TWIPS), as far as I know. And there is no nice solution to calculating the height of elements to be output... It's pain to maintain layouts built that way.


cheers

Janis

Message was edited by: Jānis B

6 REPLIES 6

Private_Member_7726
Active Contributor
0 Kudos

Hi,


I'm having hard time grasping where exactly is %TEXT9 in the sample output, but could it not somehow go in under the Table header, perferably in the %ROW2 as well? Ok, I got it, thinking of a way to combine those... Single table row can be protected (but then you probably already were aware of that).

Edit in 2: Yes, one can protect more than one row type under table header using folder. The only problem is: no matter what I try, at implicit page-break the composer looses the header contents... Seems to be a wierd bug of some kind, related to footer, because sometimes parts of contents appear even outside main window


1. How will I know how much space is left on the current page, at runtime. So that I can judge and do a page break ( Using command ) .


I take it you mean in the MAIN window, right? Only via an implicit enhancement in SF composer runtime somewhere in SAPLSTXBC that would allow you to access ft-rem_height (remaining height in TWIPS), as far as I know. And there is no nice solution to calculating the height of elements to be output... It's pain to maintain layouts built that way.


cheers

Janis

Message was edited by: Jānis B

Private_Member_7726
Active Contributor
0 Kudos

Ok, the table rows grouped under folders with page-protect seem to be very broken - at least on NW 7.02 SAPKB70211. I can reliably reproduce at least two distinct bugs related to implicit page breaks, including getting the content of page-protected header contents outside MAIN window..., and I haven't been able to find notes to fix the behavior.

A third bug, whereby contents of table header are lost at implicit pagebreak is related to adding shading or borders to main window. Sorry, don't know how to solve your requirement, but I have something to report to OSS now...

The picture illustrates one of the bugs. Fat border indicates Main window, shaded orange is the table header consisting of two rows under page protected folder, green is table body:

cheers

Janis

0 Kudos

Hi Janis,

Thank you for providing an important insight into this requirement.

Yes it is difficult to maintain layouts built with variable length of row items. However, this is something which I have to achieve in some way.

As you mentioned, if ft_rem-height with implicit enhancement works, it would help me a great deal.

If nothing else works, this is what I have planned to do. However, I am aware this is not one of the good ways.

1. Through my driver program, I will send an internal table which will send information of how many lines are each Document type acquiring.

2. With this, I will put a conditional command just above TEXT9 and do a page break when condition is satisfied. Condition would be something like : Number of lines required > Number of lines remaining in Smartform. If yes, Command would introduce a page break.

This is not something which I want to do. Because this solution will depend on Font size used.

Anyone any help please!

0 Kudos

I still believe grouping different table rows under page-break protected folder should be working and would be straightforward, transparent and easily maintainable solution for challenges like this...

I'll be reporting the weird behaviors at implicit page-breaks to SAP (I believe those are bugs), and am debugging the composer to see if I there is chance of easy fix (or if I'm maybe doing something wrong in the form). It's procedural code - lots of formroutines without parameters integrated over global data of function group, so it is pain to understand and debug... I'll let you know what the outcome will be

Could you please upload and preview the attached form in test mode to see if you also can reproduce the bug at second page-break from my previous post?

Thanks and cheers

Jānis

Edit in: actually, for the first "protect" you need - couldn't you get rid of the table and simply group the contents of %TEXT9 and %ROW2 under single template?

Message was edited by: Jānis B

0 Kudos

Hi again,

Actually, within the Main part of table node, grouping several rows under page-break protected folder works just fine... It is just that when one starts putting the page-break protected folders in Header part the things go awry. I don't believe the fix for that will be easy at all.

But since your HEADER_TABLE1 does not really need a header part to achieve same layout, I'd try as follows:

1) create page-break protected folder under Main part of HEADER_TABLE1;  add an empty column of required width for %ROW2 and drag it under folder; create a new row type to hold %TEXT9 (just one column for the whole table width and no borders) and insert it before %ROW2; disable Header and Footer part for the table; re-position the table so its aligned to data table;

2) group the SAFETY_ITEM_ROW1 and MPO_DATA_ROW1 under page-break protected folder...

Then, is there actually a reason the HEADER_TABLE1 is split off in a separate sort event? If it could go into DATA_TABLE1 main part, all elements could be protected together. Even if there is reason, you still should be able to move the contents of HEADER_TABLE1 to DATA_TABLE1, and control their output using flag set via code nodes in DOKNR_TOP event and footer of DATA_TABLE  and reset each time header rows have been output.

True, you'd have to add that empty column to the table. But that inconvenience pales in comparison to having to extricate the remaining height of Main window out of Composer innards via implicit enhancement, and the pain of having to calculate output height of dynamic layout elements in form itself and doing explicit page-breaks.


Just make sure to disable all (unnecessary) table headers and footers.

Attached form illustrates protecting the header table and Data table separately, and I've been unable to break the layout no matter what I tried . Or did you try the folders in the Main part and did not succeed?

cheers

Jānis

Message was edited by: Jānis B

0 Kudos

Ok, the solution (or rather workaround, I feel ) to this wierd behavour with table headers at page-break has been known at least since 2003, courtessy of , and is described in Note 640016 - Header is displayed twice. Basically, if I've got it right, one has to enter the minimum height of the table equal to or greater than the maximum height of table header. 5 LN minimum does fine for my example:

The trouble is: what if the maximum height of table header varies and is known only at runtime, and if the differences between possible header heights are considerable..?

I also feel that this has got to be the most unintuitive of the arcane tricks I've seen in smartforms yet...

cheers

Janis