$if 0 旼컴컴컴컴컴컴컴컴컴컴컴컴캠 PowerBASIC v3.20 旼캑 DASoft 픔컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴� � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캘 Copyright 1995 � DATE: 1995-10-01 픔� � � FILE NAME AWELCOME.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 '.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.�.� ' � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Hi and welcome to Nutz n' Boltz Text Library #3! This library is primarily devoted to direct user interface with your program. It handles menus, one-line help messages, Yes/No selections and a few other odds n' ends. It definitely goes way beyond where I had first thought of taking the text package so think of these routines as a BONUS pack! ( That sounds better than "left-overs" :) One thing that is conspicuously absent is the rodent! I don't believe it to be a viable input device for data-based programs as it takes the user's hand too far from the keyboard, is too slow, adds too much code, and is difficult to accurately position in text mode. Don't get me wrong, there is a niche for the mouse in some text mode programs and when that niche needs filling I believe it should be filled. There are only 3 menu functions but, between them, you should be able to get a real good idea of what can be done with menus! I'm not too sure that all 3 of them are really too useful in their current state as they all are truly monsters but each one does everything it has to do to serve the broadest range of programs. I use them AS-IS only when I'm in a hurry and working on a small program where memory is not a problem. When it's time to get serious then I pull them apart and use only the stuff I need/require leaving the "extras" in the BIT-BUCKET under my work bench. The Drop-Down menu (Pull-Down) is, probably the exception to the above. It is almost as tight as it can be made without loosing any of it's important functions. It can change width, height, wrapping style, etc. with just a few bytes of incoming info. It takes a few "extra" arrays to make it work but I have found that they all get real necessary in any size program so.... The "HOT" menu is the monster that really is soooooo over-done that it almost screams for stripping! The only redeeming quality is that it is almost automatic in it's reactions to the incoming set-up data that it really isn't too difficult to use once you get used to the 25+ parameters that it takes to get it working! Last of all is the INDEX menu: it is a cousin to the "HOT" menu but is so much "smarter" than the "HOT" stuff that it hurts just to think about it. I came up with the idea for this one when working on a really <<>> program that had index's on a zillion lists with two of them ranging into the 1000's! I had to give my users a way to get to any one record in as few key-strokes and little remembered data as possible. Out of my pure genius (and a couple of years of screwing around), viola (walaa), the INDEX menu was perfected. It can either "tag" a group of items or select just one but it's real power is in how the user can just start typing in a name and, within 3 or 4 keys get within visual distance of the one particular item they are looking for. There are 2 variations of this menu that do not appear here as they must be written for each and every use that you should think about: An INDEX menu that could read the items directly out of a file could be a handy addition to a program with a large index base. You would have to substitute all references to the array with whatever it took to get the data from the disk. This would include packages like E-TREE, etc. Also, it may be necessary to "unpack" an index string into something that resembled a string that a human would understand. One other application that splits these two down the middle is the BROWSE style menu. This rascal resembles more a full data screen but is, in fact, just a fancy menu. Each item is displayed separately with one, or more data fields from the record. I find this VERY necessary when you're looking for the proverbial "John Smith" and would have to have more info than a name, alone, would supply; like SSAN's, addresses, phone numbers, etc. The entry point is still this type-o-matic search featured in the INDEX menu and the display is particular to each application. The other little functions do some specific stuff and are amply discussed in the .DMO files so have a look around. If you decide to make any of these functions work with the mouse don't forget fGetEvent$ and it's support. You may find that the change-overs aren't too difficult as I've used arrays in most cases to hold screen addresses. d83)