Skip to Content

HCM Processes & Forms: The Three Scroll Bars

I’m in the midst of my first HCM Processes & Forms implementation and it has become clear to me that this technology is still a work in progress.


The biggest example of that here (and I’m told it’s an issue on other projects as well) is the dreaded three scroll bars.  It’s a user interface nightmare.  For a bit of history on the subject, SAP originally coded the application such that when displayed on a normal sized monitor the user needed to use three different scroll bars to access all the fields and buttons.  It looks something like this:




SAP released an OSS note to fix the issue (1143512, and various support packs).  This note allows the Adobe control to re-size based on the size of the window.  Sadly,  I don’t find the solution to be any better than the original problem:




As you can see in the above screen shot, only a very small amount of any given form is visible after the fix.  It does re-size the control along with the window so there is only one scroll bar, but with so little visible that’s not much more usable.


I wanted to come up with a work around to:


1) Limit the number of scroll bars necessary to use the form.

2) Maximize the amount of form visible on the screen.


I went investigating the WDA component that we use for HCM P&F: HRASR00_PROCESS_EXECUTE.  That WDA uses component QISR_UI to display the Adobe control.  QISR_UI has a method called SET_ADOBECONTROL_SIZE.  Thanks to implicit enhancement points, I was able to call this method to set the Adobe control size to something that fit my goals above.


I created a post-exit method for method WDDOMODIFYVIEW of view VIEWSHOWFORM of component QISR_UI.  In that post-exit I placed the following code using the WDA code wizard:


DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller =   wd_this->get_componentcontroller_ctr( ).

    i_height =   '790'                       " string
    i_width =    '930px'                       " string

I found 790 and 930 to be optimal for a maximized window on a screen with resolution of 1024×768 (a little smaller works better if you’re using attachments).  That screen resolution is probably rather standard these days; if your user’s screens are smaller you can always use different numbers. Make sure you have disabled the automatic Adobe resizing by setting the DISABLE_ADOBE_RESIZING parameter on the applications ASR_FORM_DISPLAY and ASR_PROCESS_EXECUTE to X.


Now for the catch.  You knew there was going to be one, right?  Fortunately, it’s pretty small. Doing just what I described above will only get you down to two scroll bars.  It’s less than three, but we can do better.  The next step to finally get down to only a single active scroll bar is to convert all your forms to a landscape layout.  That might sound like a big deal, but it shouldn’t be.  Yes, the Livecycle Designer defaults to portrait layout.  That might make sense for print forms.  But for interactive forms?  Our screens are wider than they are tall.  Why should our forms be taller than they are wide?  


It turns out that it’s pretty easy to change a portrait form to a landscape one.  I copied the form I used for reference purposes above and modified it to be in a landscape format.  I had to remove some of the instructions, but I didn’t put a lot of effort into the form.  I mocked it up just for this blog, after all. 



Designing forms with a landscape layout is even easier if you start with that design in mind. 


One more thing to note – you can still see the scroll bar for the Adobe control; it’s just not active since the form takes up less space than the control.  I don’t think there is anything to be done about it.  If you open a regular PDF in the standard Acrobat Reader you’ll see the same thing once you zoom out so that the PDF is smaller than your screen.


I know that hard coding the control size is not the most elegant solution.  Hopefully, one of you out there with more time on your hands can come up with something better and share it with us.

You must be Logged on to comment or reply to a post.
  • To avoid ‘hardcoding’, one option is to maintain the height&width for each form in a custom table and read it in your WebDynpro Method.
    • It’s funny how the most obvious solutions are the ones we forget about.

      I was actually thinking along the lines of parsing the form XML to get the height and width.  But with the exception of the duplicate maintenance (you’d have to maintain the height and width in the form and the custom table) your way is just as good, and much easier to implement.

  • Just caught this blog while going through the Adobe forms related ones (SDN does not make it very easy to locate specific sections of blogs…haha). This is an excellent summary and solution of an all to often problem on projects. This comes up time and again….and gets compounded further by how the form render in ESS vs. MSS vs. HR Admin execution of the “Start Application”. Thanks again for a great blog!
  • Hi Bryan

    I’ve just had this issue with the MSS start application and your method was suggested to me by someone else.

    However, I finally fixed it by ensuring the Height Type on the HRAS Process page and iview were both set to FULL_PAGE.


      • We also need to set the size properties(Height type) of page and iview to FULL_PAGE to eliminate the extra scroll bar for MSS start process.
        Page : pcd:portal_content/ mss.hras_process_page
        Iview: pcd:portal_content/
        Thank You,