Solid lines on hard copy
Posted in 2001
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
Dear all, SInce function fgl_drawbox() can't be used for hard copy how can I use I-4GL syntax to write a code that results a solid lines which could be printed on hard copy. Thanks .
Sadikin_Halim@app.co.id wrote in message <935tb0$fv9$1@news.xmission.com>... > >Dear all, > >SInce function fgl_drawbox() can't be used for hard copy how can I use >I-4GL syntax to write a code that results a solid lines which could be >printed on hard copy. Thanks . > 4GL reports are quite old-fashioned now. The language was designed a long time ago and there is no illusion of graphical capability at all. If you want really attractive reports then these are some of the options: *) Use pre-printed stationary and print the boring, fixed-width 4GL reports into the boxes and lines that are on the pre-print. *) Standardise on a particular style of printer (eg HP laser jets) and therefore you standardise on their control codes, and explicitly print escape codes to cause the printer to do wonderful things that the 4GL will be oblivious to. Beware that 4GL counts columns by the number of characters sent, so if you send escape codes (especially variable length ones or different length ones for different styles of printers) then you will find that the COLUMN X control in the PRINT statement is totally unusable for any lines containing escape codes. NOTE: if you do go this way, don't try "counting escape characters" and adjusting the COLUMNs, because you will have to revisit ALL your reports and do twice the work if you choose to support a new printer type in the future. Try to make a library of control strings, with supporting library functions to collect and define the strings per printer. Ideally, you could introduce a new printer purely by adding a few entries in a table. Beware that 4GL counts lines based only on the end of each PRINT statement, so if you do something that causes unusual line movement then 4GL will not stay synchronised with the paper unless you are extremely consistent and adjust the 4GL to suit. Note also that 4GL at least supports the ability to dump a file into the report, and that can be used to dump graphical lumps onto the paper. The name of the exact statement escapes me, but it's in the manual. *) Send the reports to a print-processor type of filter program. I know of people using a product called JetForm, and from what I can see you print special codes as words or similar and it takes over the rest. I don't know anything else about it but I understand it can be used to make pretty prints. I'm sure there will be others like that in the market place. *) Use a 3rd party product like Crystal Reports or similar, which are much more powerful report writers. If you use these products, beware the fact that Crystal MAY cause massive, greedy selects to be generated which can have a serious impact on performance. It's definitely a good idea to get an experienced programmer skilled in SQL optimisation to study the resultant queries and see how nasty they get. Good luck on your mission.
"Andrew Hamm" <ahamm@sanderson.net.au> writes: > *) Send the reports to a print-processor type of filter program. I know of > people using a product called JetForm, and from what I can see you print > special codes as words or similar and it takes over the rest. I don't know > anything else about it but I understand it can be used to make pretty > prints. I'm sure there will be others like that in the market place. With a little thought, one can make a report generate troff, TeX, html, or xml for post-processing. Treat the report generator like a krufty macro-preprocessor since it can still to nifty things (like sorting your report data) that are hard to do in document preparation languages. -- Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412 Ronald Cole <ronald@forte-intl.com> Phone: (760) 499-9142 President, CEO Fax: (760) 499-9152 My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B