home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / informix / 2816 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.7 KB
  1. Path: sparky!uunet!mcsun!uknet!bnr.co.uk!pipex!demon!cix.compulink.co.uk!shemminga
  2. From: shemminga@cix.compulink.co.uk (Stuart Hemming)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Display array highlist
  5. Message-ID: <memo.830395@cix.compulink.co.uk>
  6. Date: 27 Dec 92 17:49:00 GMT
  7. Sender: usenet@demon.co.uk
  8. Reply-To: shemminga@cix.compulink.co.uk
  9. Lines: 57
  10.  
  11. In-Reply-To: <1992Dec21.175031.11266@informix.com> cortesi@informix.com (David Cortesi)
  12.  
  13. TITLE: Re: Display array highlist
  14.  
  15. In <1992Dec21.175031.11266@informix.com> David Cortesi
  16.  
  17.  
  18. [Stuff deleted]
  19.  
  20. > How would you want this window defined?  Just a bare window, or would
  21. > you require a form in it?  (Your mention of DISPLAY ARRAY suggests a
  22. > form.)  So what is the relationship between the number of lines per
  23. > "page" and the dimensions of the screen array?
  24. > 
  25. > One big problem you are overlooking is that some reports are
  26. > asynchronous -- all the rows you OUTPUT just go in a temp table and
  27. > nothing actually comes out until FINISH REPORT is executed.
  28. > 
  29. > Which means that the window you would name in [START] REPORT TO would
  30. > have to still exist at FINISH REPORT time. There is no way that 4GL can
  31. > ensure that.  Not a show-stopper, but it would mean a possibly obscure
  32. > error message on FINISH REPORT (window not available).
  33. > 
  34. > In fact this would be a general problem; the program could always CLOSE
  35. > WINDOW foo in between any two OUTPUT TO REPORT lines, and in fact the
  36. > program could CLOSE the window and then reOPEN the window with
  37. > different dimensions -- or DISPLAY a different FORM -- between two
  38. > outputs!  So basically the report-display logic would have to track
  39. > what could be a very dynamic, moving target for line width and page
  40. > length.
  41. > 
  42. > That isn't a problem for your specific application I'm sure, but it
  43. > illustrates the kind of problems that would have to be dealt with for a
  44. > general implementation.
  45.  
  46. I think a better way would be to arrange to have the report generated
  47. to a file with the programmer responsible for line and page length.
  48. Then Informix need only provide a file viewer in a window. The logic
  49. for this could (should?) be very simple.
  50.  
  51. If this idea where implemented along with the dynamic report
  52. definitions (variables for output target, line and page length) then
  53. reports could be set up in apps to print on 60 line paper pages, in full
  54. screen and windowed views.
  55.  
  56. How does that grab you?
  57.  
  58. | I'm not bad, I'm just drawn that way -- Jessica Rabbit     |
  59. |------------------------------------------------------------|     
  60. | Stuart Hemming       | shemminga@cix.compulink.co.uk       |
  61. | Tudor Labels Ltd     | uunet!cix.compulink.co.uk!shemminga |
  62. | Roman Bank Bourne    | Tel :  (+44) 778 426444             |
  63. | Lincs PE10 9LQ. UK.  | Fax :  (+44) 778 421862             |
  64.  
  65.  
  66. Stuart
  67. |8-)
  68.