home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / oracle / 1131 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  2.9 KB

  1. Path: sparky!uunet!olivea!decwrl!sdd.hp.com!cs.utexas.edu!asuvax!ukma!deepthought!neil
  2. From: deepthought!neil@ms.uky.edu (Neil Greene)
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Multiple Screens in SQEL*FORMS
  5. Message-ID: <1992Jul24.142932.21840@deepthought.uucp>
  6. Date: 24 Jul 92 14:29:32 GMT
  7. References: <1992Jul24.083034.1@cc.helsinki.fi>
  8. Sender: neil@deepthought.uucp (Neil Greene)
  9. Reply-To: Neil Greene <deepthought!neil@ms.uky.edu>
  10. Organization: ARCI, Inc.
  11. Lines: 54
  12.  
  13. In article <1992Jul24.083034.1@cc.helsinki.fi> jaakola@cc.helsinki.fi writes:
  14. > In article <j1gmxq-.sjs@netcom.com>, sjs@netcom.com (Stephen Schow) writes:
  15. > > I am new to Oracle and I am working in an application that requires 3
  16. > > seperate screens that are related to each other only in the sense that
  17. > > they are part of an all encompassing application.  There are no data
  18. > > relationships between them.  I am not sure if I should create 3 seperate
  19. > > forms or 1 form with seperate pages.  Note that each screen has a master
  20. > > detail relationship.  I have set something up that uses just 1 form with
  21. > > each logical screen on a different page.  Then I will set up a menu to call
  22. > > specific pages.  
  23. > > 
  24. > > Am I doi ng this the best way?  Would it be better to make seperate forms?
  25. > Well, if they are logically separate, keep them physically separate too!
  26. > > I do NOT want to have to exit all the way back to the OS and then call  
  27. runforms
  28. > > again just to switch to another screen.  What I am worried about are  
  29. potential
  30. > What's wrong with calling separate runforms? Of course starting a new
  31. > process takes a while, and stopping and starting a fresh runform clears
  32. > your GLOBAL variables. But you can use runform which is linked into
  33. > runmenu (version 5.0), so that the menu and all subsequent runforms run
  34. > IN THE SAME PROCESS and retain GLOBALs. Or you can create a dummy form
  35. > which calls other forms.
  36. > > problems that I might run into and have to program around by putting each
  37. > > screen on a different page of the same form.
  38. > If you want to switch screens very quickly, a single form might be
  39. > optimal. Make an experiment!
  40. > > 
  41. > > ------------------------------------------------------------------
  42. > > Steve Schow    | But you don't have to use the claw, if you
  43. > > sjs@netcom.com | pick the pear with the big paw paw......
  44. > >                | Have I given you a clue......?
  45. > >                |                       - Baloo the Bear
  46. > > ------------------------------------------------------------------
  47. > --
  48. > Juhani Jaakola
  49. > jaakola@cc.helsinki.fi
  50.  
  51. In the issue of linking sql*menu and sql*forms, I just cannot get this to  
  52. happen yet.  I have tried reinstalling, recompiling and all with no success.  I  
  53. don't mind the extra processes, but sure would like to link the two  
  54. applications.  
  55.  
  56. I am running oracle v6.x.x.x, sqlforms 3.0, sqlmenu 5.0 on a NeXTcube (bsd 4.3  
  57. unix).
  58.  
  59. -- 
  60. Neil Greene
  61. ARCI, Inc.
  62. President, Kentucky NeXT User Group, Inc.
  63. Phone: 606.254.4060
  64.