Forms 6i Debugging Practices

[Greg Brown]

Does anyone have a book or paper that could
help me in the forms 6i debugging process.

Often times, I get errors that appear cryptic
or not applicable to the acutal error at hand.

I am fairly new with forms but have a good grasp of SQL.

Thanks

[DA Morgan]

Greg Brown wrote:

To be honest ... no ... I've never seen a good one.

Post the error messages and perhaps we can help.

Daniel Morgan

[Jeff]

You can look up the frm-errors in Forms' on-line help index. That's been
sufficient for understanding all errors that I've seen so far.

In article <3dfb4df.03031...@posting.google.com>,

[URNinja-ed]

- put a break in the suspect code
- run the form in debug mode
and step through the code.
use the debugger to view the system variables and the
current value of columns and variables.

a bit brief but this should point you in the right direction

Greg Brown wrote:

--
Suzuki SV650S - plop.  Gone.
Kwak ZX-6R J2 - hear the roar
 

[Michel G. Rainville]

I do not know of any book about Oracle Forms
that I would recommend. Lulushi's is the best
of those I have.

Learning Oracle requires more than one book,
the help files, the example code and some experimentation.
Books tend to be written early in the product beta cycle
and are often sketchy.

Forms help contains mistakes; for example,
the hierarchical tree became an object type, but the
sample in 6.0 is about an older way of building it
which not only doesn't work, but the PLL library is protected
so it can't be made to work.

Errors are often only indirectly related to the
cause of the problem, and not precisely localized.

Some problems are only detected at run time,
such as wrong names for data items in a block.
Search does not cover every part of the source code,
omitting the properties, for example.

Some tips:

Build the tables first, so you can use the wizards to create
data blocks. After linking tables test the default behaviour
and only make necessary changes.

If you delete and recreate a table, refresh its data block.

Watch out for the default "automatic" setting in frames,
which will undo any nicely prepared layout unless you
change it to "manual" before changing the data layout.

There are runtime parameters to trace the execution
of the program; but it generates lots of output which
is difficult to interpret. Try to use the fewest steps to
cause a problem if you use it.

ifrun60 myform record=collect log=c:\temp\mytrace.txt

In Form Builder, Tools, Preferences, Runtime, you can check
"debug messages" on. This will sometimes help you find the trigger
that contains a problem, by firing a message at the start of every trigger.

Build and test your form incrementally, so you know exactly
what just changed when a problem happens. Try not to make
too many changes at once. When a form with a consistent set
of changes is stable, make a backup.

For complex changes, try them in isolation in a separate form
with the fewest possible features, then copy all the changes.

Good luck,
Mike Rainville

Greg Brown wrote:

>Does anyone have a book or paper that could
>help me in the forms 6i debugging process.
>
>Often times, I get errors that appear cryptic

>or not applicable to the actual error at hand.