NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/database/informix/3062

Internet Message Format | 1993-01-27 | 3.3 KB

Path: sparky!uunet!digex.com!intercon!udel!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!agate!doc.ic.ac.uk!pipex!demon!cix.compulink.co.uk!shemminga
Newsgroups: comp.databases.informix
From: [e-mail] (Stuart Hemming)
Subject: No subject
Reply-To: [e-mail]
Date: Wed, 27 Jan 1993 17:03:00 +0000
Message-ID: <[e-mail]>
Sender: [e-mail]
Lines: 66

TITLE Views on I4GLMODS

FWIW here are my comments:

I4GL-R03:    Part of the functionality for this would come from I4GL-I04 where
windows are opened for help. I think that further consideration should be
given to this especially as, currently, scrolling in a window with DISPLAY is
not easy to achieve.

I4GL-M01:    I don't agree that this facility wouldn't be required if I4GL-
L10 were implemented. I believe that the is a strong case for having a system
provided, consistent method for producing vertical menus.

I4GL-F01:    All I can say is that's a shame. There is a lot of, IMHO,
unnecessary code floating about just to deal with this problem.

I4GL-F04:    A question. How difficult would it be to provide an extra system
table, sysregexp, where regular expressions could be kept and referred to from
within forms? If this method was used then the same functionality could be
used in prompts. Furthermore, users could add there own regexps to the table
meaning that *updates* from informix wouldn't be necessary to add new
*standard* regexps.

I4GL-F05:    There are a number of apps out there (I've got a few of them)
where this functionality would turn multi-screen inputs into single-screen
inputs. This would reduce the total amount of code required for an app
especially in light of I4GL-F01.

I4GL-F07:    The perverse should be taken out and shot 8-).

I4GL-F10:    Failing the provision of extended scope for the NEXT FIELD
command, allowing <fieldname> to be a string variable should allow the user
to provide this functionality for himself.

I4GL-W04:    I would add that the ability to use different graphics characters
for borders within the same app (eg. single and double lines) should be
introduced.

I4GL-I04:    I don't agree that it is necessary to provide the facility for
defining different windows for each help call. It should be sufficient to
define a help window, say, as an OPTION. Doing it this way would of course
allow those who desperately want help in deferent places at different times
to have it.

I4GL-I05:    I don't imagine that I'm the only one whose apps are littered with
flags reflecting the state of various OPTIONs. I strongly feel the this should
be moved up a class (or two).

I4GL-K01:    YES PLEASE!!!! I have acres of code that I'd gladly throw away to
use something like this.

Just a general note: aren't there a frightening number where the phrase
"...should have been done ages ago" appear?

There are many more that I have an interest in but am generally happy
with the classification.

Will we get feedback from whoever you pass this list on to?


| I work with some bloody strange people, and so do they!    |
|------------------------------------------------------------|
| Stuart Hemming       | [e-mail]       |
| Tudor Labels Ltd     | uunet!cix.compulink.co.uk!shemminga |
| Roman Bank Bourne    | Tel :  [phone]             |
| Lincs PE10 9LQ. UK.  | Fax :  [phone]             |