This content has been marked as final. Show 11 replies
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...
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 18.104.22.168 and 22.214.171.124, yet you are using 126.96.36.199. 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 (188.8.131.52 and 184.108.40.206) 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?
Oracle Forms Product Management
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.
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.
<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>
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.)