home *** CD-ROM | disk | FTP | other *** search
- SOME MISCELLANEOUS LIBRARY ROUTINES I'VE TOSSED IN
-
- GETINT.LIB
- You pass a message and the minimum and maximum values and this function
- asks for a value to be entered. It will not proceed until the value
- falls within the designated limits. This avoids unpleasant surprises
- when someone enters bad data. I'm afraid compilers aren't quite as
- unforgiving of this problem as are interpreters. Often, a lot of data
- is lost through a little foul-up.
-
- CAPCHAR.LIB
- CAPSTR.LIB
- The former makes lower case letters into cap ones, the latter passes
- through a string capitalizing where necessary. Numbers and symbols
- are unaffected.
- I'm not sure, but I suspect that the boolean comparison used
- here is more efficient than the set-inclusion test used in Z-UG's
- STRLIB.
-
- PADSTR.LIB
- DEPAD.LIB
- PADSTRr sticks spaces at the end of a string until is hits the length
- passed as part of the function call. I implemented this as a function
- so that the original string can be left intact if desired.
- This serves two purposes:
- [1] Pretty printouts, since ver 3.2 pads strings to the left, just
- like numbers, rather than to the right, which means that simply going
- str:20 isn't satisfactory.
- [2] Microsoft stores strings in random access records padded with
- blanks rather than with a length byte [used in Pascal/Z]. Personally,
- InterSystem's approach has its advantages, since you get back exactly
- what you stored, rather than a fixed-length string. But I also have
- SuperSort, which does not support the length byte [although it can
- always be passed over in setting up the keys], which means that padding
- the stored records prevents unpleasant surprises during the sort.
- DEPAD starts dropping spaces off the right side of a string until
- it hits the first non-space character. Again, this is a function rather
- than a procedure, in case the original string needs to be left intact.
-