Re: Forms 4.5 help

Dave,

The threshold decision is whether to use one form (your options 2 and 3) or multiple forms (your option 1).

First, consider the size of the application. You don't want the form to become so large that runtime performance suffers.

Next, consider how frequently the application will be navigating between screens, and how often will one screen need to reference blocks and items on another screen. In other words, how closely related are the screens? If there will be a lot of cross-screen navigation, you probably want to keep everything in one form, so you can easily reference items using :block_name.item_name notation. With multiple forms, Form B cannot directly reference an item in Form A, so, you will need to establish global variables or pass parameters between forms. Managing these parameters and global variables increases design overhead.

Next, consider modularity. Do the 6 screens form an indivisible unit, or might they operate independently? In other words, could one screen ever be "spun off" into a separate application? If so, then that is a reason in favor of developing that screen as a separate form.

Last, how many developers will be working on the application? If you are the only one, then you can keep everything in one form. But if there are multiple developers, then each one needs to develop a separate form (for the same reason that two people cannot work on the same Excel spreadsheet at one time).

For general ease of development (KISS), I would try to keep everything in one form. I would go to multiple forms (i.e., increase complexity) only if there is a good reason to do so. From the brief description of your application, it sounds like it is small enough that you can safely keep everything in one form.

If you decide to use one form, then you have to decide between each canvas having its own window (your option 2) and one window for all canvases (your option 3). I think this is strictly a personal decision based on what is easiest for the developer. I use option 2, because I find it easier to manage the window-canvas relationship this way. I can set the properties of each window at design time, and I don't have to issue SET_WINDOW_PROPERTY statements to change the window title, etc. On page 423, Lulushi also recommends establishing a one-to-one relationship between canvases and windows. However, if you prefer option 3, I can't think of a good reason to dissuade you.

Finally, if you decide to use multiple forms, then you need to decide between OPEN_FORM, NEW_FORM, and CALL_FORM. There are slight differences among the functionality of each, and the choice depends on the functionality the application requires. On pages 575-582 Lulushi discusses the relative merits of each. Also, Dr. Paul Dorsey of Dulcian, Inc. has a compilation of Forms tips and techniques at http://www.dulcian.com/top20forms.htm. Tip #13 discusses the relative merits of each.

I would add that Forms 4.5 has a known bug, #303965, which causes a FRM-40401(No changes to save) or a FRM-40405 (No changes to apply) error message to occur on subsequent updates to a form issued with an OPEN_FORM(NO_SESSION). This bug was scheduled to be fixed in Developer/2000 Release 2.

Hope this helps.

Todd Owers

dave_at_potts-mullarkey.co.uk wrote in article <6cefgr$2m5$1_at_nnrp1.dejanews.com>...
> I am developing a small Forms application which will consist of a menu
 screen
> and 6 options from it (activated by pushbuttons.)
>
> Reading my manuals it seems I can achieve what I want by a number of
> different routes:
>
> 1. Each screen is created as a stand alone form and is called from the
 menu
> using OPEN_FORM, NEW_FORM or CALL_FORM.
>
> 2. The 7 screens are created as 7 separate canvas views within one form
 and
> each has a unique window attached to it
>
> or the option I am currently developing
>
> 3. The 7 screens are created as 7 separate canvas views within one form
 and
> all use the same window (the canvas views are called from the menu using
 the
> REPLACE_CONTENTS_VIEW built in attached to a WHEN_BUTTON_PRESSED
 trigger.)
>
> I am using the on line developers guide and a book by Albert Lulushi
 called
> Developing Oracle Forms applications. They both seem to indicate that
 all
> three of the above will result in a working solution. What they don't
 say is
> why I should choose one in preference to the others.
>
> If anyone can help with an explanation and/or other books that are good
 for
> reference I would greatly appreciate it
>
> Thanks
>
> Dave
>
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/ Now offering spam-free web-based newsreading
>
  Received on Wed Feb 18 1998 - 00:00:00 CET