11 Replies Latest reply: May 16, 2013 2:49 PM by lake RSS

    printing: a new forms feature we want.

      Users expect to print forms. We need a way to do it. I am using and the users tried printing
      from it. It prints but it's micro-sized, not big enough. A use for forms is enter some of the data here,
      enter some of the data there and then someone who needs to the data calls up the same form at
      yet a 3rd location and prints it. Someone else calls up the form at a 4th location and prints it. The idea being not having to pass paper files around from building to building. This would be a really really good idea for the next version of forms!
      (And btw it would be best if it worked on forms larger than one piece of paper.) This could be a larger project like how to get forms to play nicely with some pdf program or some word processing program or
      some spreadsheet program. That could take care of printing plus the highly desired by the users ability
      to interact with the products they love to use. (I don't but they do.)
      In the future this could expand to charts and that type of thing.
      (It needs to be easier to handle than webutil! )
        • 1. Re: printing: a new forms feature we want.
          Amatu Allah Neveen Ebrahim
          Hi Lake
          its all about ur Printer Set Up Page it's type ; it might be set to letter size by default pls chage it according to ur paper size e.g A4 accordingly u can Set the Width & Height
          It has nothing to do with forms...

          Amatu Allah
          • 2. Re: printing: a new forms feature we want.
            Christian Erlinger
            The proper channel for Enhancement Requests would be filing a SR with Oracle Support I guess.

            However as for your idea itself to me this sounds like a reporting solution. Of course you'd have to create a report for each form you'd want to print, however; when looking at our forms it is doubtful that printing them would bring joy to our users. That's why we have reports (oracle reports, oracle discoverer, OBIEE on our side) to bring the data in a desired format and print them to whatever medium you desire...

            • 3. Re: printing: a new forms feature we want.
              Users expect to print forms.
              Really? I've never/rarely seen anybody here use the Print option. That's just a screen shot. Sure, users want reports, but there are plenty of options for that.
              • 4. Re: printing: a new forms feature we want.
                Michael Ferrante-Oracle
                Thank you for your suggestion. As you can see from the feedback, there are several existing options.

                Let me start by saying that if you are having any problems with any product, I generally would recommend that before spinning your wheels trying to troubleshoot it you should consider applying the latest patches to all associated layers. Most times in cases where the failing behavior seems like a defect, the issue likely has already been addressed in the current releases. For example, with regard to Oracle Forms, the latest releases are and, yet you are using Also, in your case, because part of the printing functionality comes from the client side, using the latest Java version (on the client) might be helpful. The latest supported versions for these Forms versions ( and are Java 6U45 and Java 7U21. If you haven't tried the latest patches to overcome whatever issue(s) you are having, it may be worth trying on a test machine.

                Regarding the Forms existing "Print" feature, this is simply a way to do a screen shot of the form. How valuable that print out can be will be directly related to how the form you are printing was designed (the gui). If it was designed with printing in mind then it might consist of only text or display fields that hold the data. In other words, it would have a small or non-existent number of buttons, images, and other objects that would not add value to a printed screen shot. As for how this works, in general the printout should be scaled to fit on a single page. So if your form (window/canvas) is very large, the printout might be very small so that it can fit on one page.

                Are you ok with the fact that the Print feature is a screen shot? Or would you prefer a "reporting" option? As mentioned, Oracle Reports is ideal for that task. However, what if Forms could output a simple, unformatted report for cases where using Oracle Reports may be overly complex for such a simple task? For example, in a csv or other similar basic format. Would that be of interest to you or others?

                Michael Ferrante
                Oracle Forms Product Management
                • 5. Re: printing: a new forms feature we want.
                  Forms enhancement was brought up by the recent poll. We're never going to get anything if we don't ask for it. And get other people to do it.
                  • 6. Re: printing: a new forms feature we want.
                    yes Mr. Ferrante it i definitely s a screen shot. And that is useful but we have forms larger than a screen. Secondly even in the case of a form that does fit on a single screen, printing it from forms ends up much smaller than the screen in both directions. I imagine this relates to the logic looking at how wide the actual screen is and then scaling it down to the much smaller paper. For example right now I'm using a screen that is 21 inches wide, about 2 1/2 pieces of portrait orientation paper wide. Imagine I bring up a form that turns out to take up 7 1/2 inches in width and I want to print that to paper that is 8 1/2 inches x 11 inches. What happens is the program is possibly looking at the possible size of the screen and not the actual size of the form? So it scales it much smaller to print, I'm guessing. We are using 6u45 btw. I don't doubt that getting printing to work well is rugged but it can be done. For example browsers do it (albeit not always perfectly). Users think 'there is that stuff I need in the form in the browser, I should be able to print it like any other web page'. Since the applet has disengaged itself from the browser apparently, we can't ask the browser to do the printing, right?. (It'd be great if we could!) So the only choice is forms (or some other java code finagled in there.) It would be such a great feature, to be able to print forms without creating a duplicate of the form so to speak in reports just to do the printing.

                    If you could summon adobe reader, msword, excel and so forth from forms, passing a temporary file, that would probably solve the printing issue in many cases because they could print it depending on what the form looked like. Also users love to get data into their favorite applications anyway. (Speaking of this forms needs some work on copy and paste. It could definitely be better about users being able to copy data from forms and paste data to forms.)

                    I definitely think anything you can do to enhance forms printing would be highly appreciated. One of the good things about forms is you can create enormous forms and it all works fine. But the form content of course extends way "below" the visible screen.

                    The csv thing (I'd vote for tab delimited but whatever one would do it would be highly advisable to make the delimiter user-selectable) would be a great idea. We would love to be able to save data from a form as a tab delimited file (on the client). For example we have forms that do a lot of logic and user action to select certain names and addresses. Then they want to get that information into msword for mail merge to create labels and letters.
                    • 7. Re: printing: a new forms feature we want.
                      Michael Ferrante-Oracle
                      You are exactly correct. The more we talk about it, the more likely it will be that we can add what you want. I am open to any suggestions. However, as I mentioned on another thread, there are only so many new features we can add in the time available. Another important factor we consider is whether or not adding the new feature could put other existing features at risk of destabilizing. And, we also want to ensure that if we change or extend an existing feature, existing applications (fmb, mmb, pll) do not need to make code changes in order to work in the new version. The idea is that when moving from version to version, we will do our best to ensure that all you need to do is just recompile.

                      If anyone has any ideas for features, even if they have been mentioned before, please do not hesitate to start a discussion about it. If it seems that there is a large demand for a particular feature, we will investigate adding it. However, if only one person makes a suggestion and no one else finds interest in it then adding that feature becomes less likely.
                      • 8. Re: printing: a new forms feature we want.
                        François Degrelle
                        <p><i>"...We would love to be able to save data from a form as a tab delimited file (on the client)..."</i>
                        To solve part of your problem, you can get a generic .PLL method to extract table-block contents to the clipboard, so that it is easy to paste within Excel or MSWord application.
                        The LAF project has what you need in the laf.pll file - procedure COPY_FROM_BLOCK(). As this tool is free, you can download it to extract that procedure from the PLL and use it in your applications.<p>
                        • 9. Re: printing: a new forms feature we want.
                          thanks Francois! I didn't know plsql could stick data into the clipboard. That is a fine idea! I'll check it out.
                          • 10. Re: printing: a new forms feature we want.
                            François Degrelle
                            Actually, it is a JavaBean that puts the data in the clipboard, but as you told about creating a local machine file, you can just add some CLIENT_TEXT_IO() instructions to that procedure to do what you need.

                            • 11. Re: printing: a new forms feature we want.
                              thanks but I need it on the client: (from help).
                              "Text_IO operates on the application server machine, not the client"

                              Next you're going to say webutil but I've had no luck getting it to work.
                              I think I need to create my own bean and then I can rail at myself for it not working :-)
                              (Cut out the middle person. Much more efficient.)