suppressing warning messages

[Edis, Bob]

Chris

It sounds to me like you've proved the necessity of the warning messages! :)
If most have caveats associated with them, then there is a real requirement
to see the messages at compile time, at least at first compile.

Regards,
Blue

-----Original Message-----
From: Chris Sharman [mailto:chris.sharman@ccagroup.co.uk]
Sent: Monday, July 02, 2001 9:45 AM
To: Deskin, Bob; powerh-l@lists.swau.edu
Subject: RE: suppressing warning messages



>You know you're damned if you do and damned if you don't. This warning and
a
>number of others, are conveniences that indicate potential problems.
>Unfortunately if lots of them get issued, they lose their value. I don't
>know about this particular warning, but many of the warnings we issue are
>there because a customer complained that we didn't issue a warning. Sigh.

Well, yes, I see your point.
Other languages I've used, however, provide a way to write clean code.
If Powerhouse provided a way to get a clean build, it would be much nicer,
particularly when doing mass compiles during a PH upgrade. I'd be willing to
live with informational messages (*I* or whatever), but I'd like to avoid
code compiled with warnings.

Common warnings we ignore in Powerhouse, because they come up frequently, we
know of no way to avoid them, and they don't represent a problem.

*W* PowerHouse name for
      This occurs in QTP/Quiz when a subfile has an explicit device or
      directory. It can be fixed for QTP using ALIAS, but not for Quiz.
      OK - really just informational

*W* This screen requires that the executing terminal support 132 columns.
      This occurs in QDESIGN for 132 column screens
      OK - really just informational

*W* Duplicate item name in subfile description : FILLER
      OK - Allow any number of filler fields in a record

*W* Values displayed in SELECTBOX will be scrolled.
      This occurs in QDESIGN where too many values exist for the box.
      Avoid if possible by using a bigger box
      OK if unavoidable

*W* Update on linked screen may bypass PREUPDATE/UPDATE/POSTUPDATE
procedures.
      This occurs in QDESIGN where non-default [PRE|POST|]UPDATE
procedure(s)
      exist and there is a subscreen.
      OK *provided* the subscreen doesn't update

*W* The item for this field has a final value.
      OK *provided* it's ITEM item FINAL FIRST(item) on repeating item

*W* Set to the same occurrence as the AUDIT WITH file specification.
      Problems with cache/audit with on 7.10 - accept for now.

Regards,
Chris



-----------------------------------------------------------------------

Any views expressed in this message are those of the sender and not
necessarily those of CCA Group.  The unauthorized use, disclosure,
copying or alteration of this message is forbidden.  The contents of
this message may be confidential and/or privileged, copyright CCA Group
and are intended solely for the use of the individual or entity to whom
they are addressed.  Whilst this message has been scanned, CCA Group
cannot guarantee that it is virus free or compatible with your systems
and accepts no responsibility for any loss or damage arising from its
use. The recipient is advised to run their own anti-virus software. If
you receive this message in error please contact
postmaster@ccagroup.co.uk immediately, destroy any copies and delete it
from your computer systems.

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.