home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / oracle / 1127 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.3 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!cc.helsinki.fi!jaakola
  2. From: jaakola@cc.helsinki.fi
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Multiple Screens in SQEL*FORMS
  5. Message-ID: <1992Jul24.083034.1@cc.helsinki.fi>
  6. Date: 24 Jul 92 06:30:34 GMT
  7. References: <j1gmxq-.sjs@netcom.com>
  8. Sender: news@klaava.Helsinki.FI (Uutis Ankka)
  9. Organization: University of Helsinki
  10. Lines: 37
  11.  
  12. In article <j1gmxq-.sjs@netcom.com>, sjs@netcom.com (Stephen Schow) writes:
  13. > I am new to Oracle and I am working in an application that requires 3
  14. > seperate screens that are related to each other only in the sense that
  15. > they are part of an all encompassing application.  There are no data
  16. > relationships between them.  I am not sure if I should create 3 seperate
  17. > forms or 1 form with seperate pages.  Note that each screen has a master
  18. > detail relationship.  I have set something up that uses just 1 form with
  19. > each logical screen on a different page.  Then I will set up a menu to call
  20. > specific pages.  
  21. > 
  22. > Am I doi ng this the best way?  Would it be better to make seperate forms?
  23. Well, if they are logically separate, keep them physically separate too!
  24.  
  25. > I do NOT want to have to exit all the way back to the OS and then call runforms
  26. > again just to switch to another screen.  What I am worried about are potential
  27. What's wrong with calling separate runforms? Of course starting a new
  28. process takes a while, and stopping and starting a fresh runform clears
  29. your GLOBAL variables. But you can use runform which is linked into
  30. runmenu (version 5.0), so that the menu and all subsequent runforms run
  31. IN THE SAME PROCESS and retain GLOBALs. Or you can create a dummy form
  32. which calls other forms.
  33.  
  34. > problems that I might run into and have to program around by putting each
  35. > screen on a different page of the same form.
  36. If you want to switch screens very quickly, a single form might be
  37. optimal. Make an experiment!
  38.  
  39. > 
  40. > ------------------------------------------------------------------
  41. > Steve Schow    | But you don't have to use the claw, if you
  42. > sjs@netcom.com | pick the pear with the big paw paw......
  43. >                | Have I given you a clue......?
  44. >                |                       - Baloo the Bear
  45. > ------------------------------------------------------------------
  46. --
  47. Juhani Jaakola
  48. jaakola@cc.helsinki.fi
  49.