$if 0 旼컴컴컴컴컴컴컴컴컴컴컴컴캠 PowerBASIC v3.20 旼캑 DASoft 픔컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴� � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캘 Copyright 1995 � DATE: 1995-10-01 픔� � � FILE NAME A-MUST .TXT � by 突袴袴袴袴袴袴袴羔 � � � � � Don Schullian, Jr. � � � 突袴袴袴袴袴袴袴袴袴袴袴袴暠 � � � A license is hereby granted to the holder to use this source code in � � � any program, commercial or otherwise, without receiving the express � � � permission of the copyright holder and without paying any royalties, � � � as long as this code is not distributed in any compilable format. � � � IE: source code files, PowerBASIC Unit files, and printed listings � � 突佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � � .................................... � 突袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� $endif This library includes one of the most important routines any data program will use: fTinput$. (No brag, just fact.) There are sufficient files here to get you up to speed with this function but what I want to discuss here is data input, in general. How you store data on the disk, how you use it in the program and how the users sees it do NOT have to be the same things! In fact, its usually the best bet to NOT use and store the data the way the users sees because the human brain and the CPU don't work the same way. Dates and Times are two good examples of this. Both of these can be stored in two bytes but can take up to 10 bytes to display so the human can understand them. While in the two byte format they can be added, subtracted and stored quicker than when in the 10 byte format. Another VERY important part of a data base is the input and use of names. In America the average length of a name is about 17 characters. Of course that includes Last First Middle-Initial but leaves no room for titles and honorifics. Also it is quite insufficient for truly long names! And most programs I have seen force the user to remember the format the name is to be input in! That's dangerous because users are part and parcel of an age old law first expounded by Mr. Murphy! You HAVE to protect them from any and all possibilities of screwing up! Then you have different name styles in almost every country around the world, so, nothing is sacred. To help relieve this problem I devised a 3 field input system that keeps the user honest, allows for variable length parts and lets the computer do the job it was designed to do. I've gone into all this in a previous library but I'm going to do it all again 'cause IT IS IMPORTANT! Your program presents the user with 3 separate fields whose total length are longer than the final acceptable length of the packed data: Last or Family Name: Public________________________ 30 chars First and Middle Initial: John Q._______________________ 30 chars Honorifics: Mr., III_______ 15 chars This stops the user from entering: John Q. Public, III Mr. John Q. Public, III Public John Q. Mr.,III and a host of others instead of: Public, John Q.(Mr.,III) which is still kind'a confusin'! You take the 3 fields F1$, F2$ and F3$ and run them through a little routine like: N$ = LTRIM$( F1$ ) + CHR$(0) +_ LTRIM$( F2$ ) + CHR$(0) +_ LTRIM$( F3$ ) to pack them up into one string. You have only to make 2 tests on this string before accepting it: 1) is the "packed" length of the 3 names =< 37? 2) are all the characters in the name acceptable? Some languages (Greek for one) have letters that look like English but have different ASCii values and if an English "M" is inserted into a name where the Greek "M" (Me) should be the data will not sort correctly and the user may not be able to find the name afterwards. Now that everything is correct and within the allowable length you can do just about anything you want with it! Because you used CHR$(0) to separate the fields and you've stored the fields in the correct order you could UCASE the whole thing to make an index reference, store the whole thing to the record as one field, or use one of the name display functions to display any or part of the name for different uses. SEE: fDisplayName$ The most important things are that you have: 1) almost guaranteed that the incoming data is in a format that is correct and usable by the program 2) there is/was sufficient room to input the separate parts of the name without forcing the user to compromize any one part. ie: Mrs. Jane A. Hyatt-Papadopoulous, PhD. unpacked full length Hyatt-Papadopoulos|Jane A.|Mrs., PhD. packed at 37 chars Yes, I know this seems to throw a bit more work on you, the programmer, but, believe me, it saves hours trying to explain to your users how vital it is to input the names "in the correct format" by forcing them to do so. It also saves hours of digging through data bases for "lost" records that were actually mis-filed because someone input Jane Doe instead of Doe, Jane. I this is true because I've spent those hours time and time again. I've even gone looking for bugs in the indexing routine(s) that I KNEW were good! It is also more acceptable to the users, I've been told, because it allows you to use names in several different ways for display, reports, menus, etc. which help the users get through their tasks easier. In short, it's just better than most of what I've seen over the years! Thanks, and happy hunting...... d83)