Power-Programmierung

home *** CD-ROM | disk | FTP | other *** search

/ Power-Programmierung / CD1.mdf / basic / library / qb_pds / grafik / glib / macro19.doc < prev next >

Wrap

Text File | 1991-06-26 | 69.7 KB | 2,114 lines

GLIB Macro-Routines Copyright (C), InfoSoft 1987-1990, 1991 GLIB contains and premieres several more complex routines not available in ANY other library collection whatever the price. These routines do more, much more, than the average call to simply save the screen image or whatever. These are more like complete programs in themselves, yet they remain callable from QB (and in some cases 'C') to perform a function, or set of functions. For lack of a better term, we are calling this type of callable routine a macro-routine to differentiate them from simple calls or primitives available from most other run of the mill library collections. In spite of the fact that these tend to be far more complex and functional than a typical sub program primitive, they tend to remain mainly assembler; they may have the look or profile of a higher-level BASIC routine, but most remain in high-speed assembler. Only MFed and FlexMenu are in BASIC. GLib Macro Routines A. MFed - A complete input handler for editing input or that supports MACROS B. Clock - An installable and accurate time display. C. QCalc - A complete, full featured calculator. D. FlexMenu - All purpose, flexible menuing routine E. StatLine - A set of status line control routines. F. DialogBox - A lightning fast way to perform short I/O functions with an end user. Copyright (C) InfoSoft 1986-1989, 1990 A. Macro Input Editor Copyright (C) InfoSoft, 1987 - 1990, 1991 I. Introduction There are several, indeed many, text input handlers around now you have now stumbled upon the most functional of them all. MFed is fully modular, requires no event trapping switch and is packed with features. MFed was designed to be a powerful all-purpose input control editor suitable for virtually any and all keyboard input situation, yet still remain modular, self contained and requires a minimum of overhead. In short, it provides for maximum functionality with a minimum of set up, dependencies and overhead. MFed, which stands for Macro Field Editor, is modular: it can be called from the main code of most any another program very easily. MFed is highly configuarable: You can change most any of the operating parameters with the change of a flag or two. MFed does not require the use of any event trapping switch, it identifies extended key codes on its own, like most any text input routine should. Finally, MFed utilizes the awesome power of macros. This allows the end user to save loads of keystrokes even redefining them on the fly if you choose! Even if you do not use macros in your application, MFed remains a highly useful and powerful text input control module. Copyright (C) InfoSoft 1986-1989, 1990 II. MFed Parameters, Syntax MFED uses several switches and 2 arguments to control the flow and text input. The formal or direct parameters are: Text$ - The text string to edit. FSize - An integer telling MFED the maximum length allowed for the TEXT$, the current text to be edited. Macro$() - An array of strings for use as macro assignments to the ALT + Alpha keys You should understand that you can actually use any names that suit you in invoking MFED. That is, you could use ED$ instead of TEXT$, or T$, or whatever you want. MFED will operate just as ex- pected, as long as you pass them in the right order. The correct syntax is: MRetCode = MFed(text$, fsize%, Macro$()) The importance of FSize is that MFed will not allow input after that maximum size is reached, and maybe beep (bleep actually). MFed does not change FSize on the return, so be sure to reset it for each successive call. III. Incorporating MFED to your code MFed works off of 3 formal arguments (covered above) and several COMMON parameters shared with the main, calling program. This allows you to share some parameters with MFed very easily such as Foreground Color, upper casing etc. The actual use and meaning of these common parameters are covered later, here we are explaining how to set up for MFed to work in your program. This is done by simply including the following line in the beginning of your main code: COMMON /MFedVars/ fg%, bg%, fgd%, bgd%, Alarm%, bad$, editted%,_ hatch%, Mac%, nums%, num$, upcase%, RngLo#, RngHi# It is important that you list them EXACTLY as shown, ie in the order shown, WITH the type declarations. The first four are fore- ground and background colors and the rest are listed alphabetically. Copyright (C) InfoSoft 1986-1989, 1990 Note that such COMMON statements must appear in your code BEFORE any executable statements. If you are not familiar with the use of COMMON it is suggested that you review this in the QB man- ual(s). Also refer to the MFedDemo source for proper set up. In implementing the MFed variables, we have opted to make several of them COMMON to allow MFed to read and literally share these variables with your main program and at the same time, keeps you from having to pass all of them as formal arguments to MFed. That is, intead of: MCode = MFed (t$, fsiz, Macro$(), fg, bg, fgd, bgd, alarm,_ editted, nums, num$, upcase, URng#, LRng#) all we do is: MCode = MFed(t$, fsiz, Macro$()) Additionally, a benefit of this is that the COMMON switches are typically used or reset MUCH less often in use than say, the text$ would be; for example, most likely you would set the color switches once (fg, fgd, bg and bgd), but text$ gets changed at almost every call. The use of a blockname (/MFedVars/) prevents MFED from interfering with other COMMON or COMMON SHARED variables, more precisely, it allows the USE of additional COMMON or COMMMON SHARED variables. To name additional variables as COMMON declare them like this: DEFINT a-z COMMON SHARED /MFedVars/ fg%, bg%, fgd%, bgd%, Alarm%, bad$,_ editted%, hatch%, Mac%, nums%, num$, upcase%,_ RngLo#, RngHi# COMMON SHARED /newblock/ arg1, arg2, arg3 ' different block COMMON SHARED a,_ ' "blank" block of b,_ ' COMMON variables c,_ z Note that /MFedvars/ need not carry the SHARED attribute, but the use of a blockname allows MFED to share those variables that it needs and ONLY those, ie a SIZE error is not encountered if you use other COMMON variables. This allows for maximum flexibility. Of the /MFedvars/ variables, only EDITTED, a more or less aux- iliary flag is ever altered by MFed. Copyright (C) InfoSoft 1986-1989, 1990 IV. Internal Editing Keys Internally, MFed does several things to provide a set of powerful, professional editting functions to it's operation. First, lets look at the editting functions and keys recognized: [Home] Places cursor at start of text or field. [End] Places cursor at first blank at end of the text. [Ctrl-End] Clear line from cursor to end of line. [Ctrl-X] Clear all text from current field. [Ctrl-U] Undoes current edit. This does not restore the text to it's form in a disk text file, but restores the text to the form it was UPON ENTRY TO MFED. It cannot know what the text was or what form it was in PRIOR to the CALL. Arrow Keys Move one character Right or Left. MFED will not allow the user to Cursor right into the hatched area if that means that more than 1 space trails the text. That is, via the the right arrow, it will not allow more than 2 consecutive spaces, as in "J. DOE " or "J Q Public". Multiple spaces can be achieved via the insert key or space however. Ctrl-Arrow Moves one word right or left Keys [Tab] Moves over 5 spaces without disturbing text. [Back Tab] Back up 5 spaces without disturbing text. [Ins] Insert works as expected, allowing text to be inserted at the cursor, and changes the cursor to a block. The Insert state is toggled off upon exiting MFed or "finishing" the field or text. [Del] As expected, deletes characters right of the cursor. [Alt-A] Invokes macro tied to that key if your program is to [Alt-Z] allowing Macros. Copyright (C) InfoSoft 1986-1989, 1990 V. MFed Return Codes - FCODE Another major feature of MFed is the returns code. This indicates to you what key is pressed to exit the routine and therefore can indicate other functions to be handled by your code. MFed Returns: Location error - -1 Enter - 0 Up Arrow - 1 Ctrl PgUp - 5 Dn Arrow - 2 PgDn - 6 PgUp - 3 (Return codes 7 and 8 not used) PgDn - 4 Escape - 9 F1 - F10 returns 11 thru 20 Note that shifted function keys are not trapped or returned, and returns 7 and 8 are omitted to allow function keys to return intuitive values. By acting on the return, MFED acts not only as a text input control module but also as a virtual control center: your application can respond to F1 with Help, F2 to search for a string, F3 to add a record and so forth. The return of a -1 code indicates that you have attempted to execute the MFed editing functions too close to the edge of the screen. For example, attempting to edit a field of 8 past postion 72 on the screen will return this. This simply precludes a runtime error by exiting gracefully. VI. Internal Handling, COMMON Parameters MFed does a few things internally on its own and a few others you control and change throughout the course of your program by resetting the COMMON parameters. If you are not familiar with SHARED parameters you should refer to your QB manual. These are not passed as formal arguments inside the parentheses when the program is CALLed but are set in your main program. o The ALARM parameter indicates whether sound is to be on or off. The sound is more of a bleep than a beep. If this switch is set (non zero) it allows the bleep sound effect to sound at various times: Copyright (C) InfoSoft 1986-1989, 1990 - An attempt to cursor right when the string has reached FSize (maximum length). - An attempt to enter an invalid character (an alpha character when nums is ON). - When an inserted character will cause the text to exceed the maximum length. - Cursor left attempted left of first character position. - If cursor right appends more than 1 successive blanks to the text. Regardless of the state of ALARM, MFed disregards any such illegal activities. Alarm just adds an error sound to the process. While the error sound has it's uses, thre are times when it is inap- propriate, such as in an office bullpen setting where such BLEEPING would be annoying - here, clear the Alarm flag (Alarm = 0). o MFed also highlights the current text or data as well as providing the hatching. When the editing is completed, and one of the 15 FCODE keys are hit to exit the field (actually MFed is exited, and control is returned to you), the highlighting is turned off. This color control is handled thru the use of 2 sets of color codes: FG, BG and FGD and BGD. These must be assigned valid BASIC color codes in the course of your main code. At the start, MFed uses the FGD, BGD (as in ForeGround_Data and BackGround_Data) colors and upon exiting, redisplays it in the FG, BG colors. These only need to be set once. o BAD$ allows you to define invalid characters. One instance where this is extremely handy is when the input will be written to a sequential file and you want to preclude excess commas from being written. Defining BAD$ as "," would cause MFed to reject commas from being input and sound the alarm (depending on the state of ALARM). o EDITTED is treated as a flag to indicate that the text string upon exiting MFed is different than it was at the start of the CALL to MFed. This allows you to test to see if field in a record has been altered. MFed only sets it to 1 never to 0. Since MFed is just handling the input for different strings, it never knows when a set of fields equalling a full record is completed. EDITTED is how MFed tells you that something has indeed been edited. ( Based on this flag, you can include code in your application to flash a message that an EDIT is in process, as is done in MFED-DEMO. It is also useful in precluding certain functions if an edited record is not saved. An example of this is shown in MFED-DEMO where paging is disallowed if a record is edited and unsaved.) Copyright (C) InfoSoft 1986-1989, 1990 o HATCH allows you to redefine the hatching character. Using the value of FSize as the maximum length allowed, MFed provides hatching from the end of the actual text to that maximum length. If a string is longer than FSize upon entry to MFed, it is truncated to the maximum length. The default character for hatching is ASCII 176, but can be set to anything you wish the HATCH variable. o MAC allows you to enable or disable macro processing. If set to 1, macros are enabled, and pressing Alt+ 'A' to 'Z' invokes the macro you or your application has assined to that key. If MAC is cleared or set to 0, macros are not allowed and ALT keypresses are ignored. o RngHi# and RngLo# allow for internal range checking of values. If RngHi# does NOT equal RngLo#, then range checking will be in effect. In this state, if an exit key is pressed (Enter, Up Arrow etc) AND the value of the string being editted is LESS than RngHi# AND GREATER than RngLo#, then MFed will consider the string to be invalid and ONLY exit if the exit key was [Esc] (this allows a way out of MFed even with 'invalid' input). If Alarm is active, it will sound on such invalid values. o Input can be limited with the NUMS switch. Originally intended to allow numbers only, it restricts input to the characters in num$. For example, in a phone number entry the characters "()-" may be allowable beyond 0-9, but in a dollar based entry $ and "." may be allowable. So prior to invoking MFed, NUM$ would be set to "1234567890()-" for phone numbers, or ".1234567890$" for the dollar based entry. If NUMS is set (1) and NUM$ is clear ( "" ) the default is "-123456789". Obviously, this allows other limited inputs such as in gender selections of M or F. Here, set UPCASE to 1, NUMS to 1 and NUM$ to "MF". o Caps or uppercase input from the keyboard can be forced on the fly (ie without a separate call) via the UPCASE switch. Set UPCASE to 1 or non zero for caps, 0 for to allow either lower or upper case. When UpCase is set, it converts the input to Upper. Copyright (C) InfoSoft 1986-1989, 1990 VII. Macro Processing MFed acts upon Alt-alpha keystrokes to insert the string associated with that combination into the field being edited. The power of this comes in applications that require repetitive stings to be typed (such as city names). If your application requires that the end user needs to type 'Shawnee Mission' or 'Overland Park' with any sort of frequency, you could assign then as macros to the [Alt-S] and [Alt-O] respectively. From there on, those strings could be entered into the current field with a single shifted keystoke. For your end user's added convenience, you can embed an exit key to the end of a macro eliminating that step too! Specifically, you could add CHR$(13) to either (or both/all) macros and after MFed fills the field with the macro contents, it exists with FCode 0! Only [Enter] (CHR$(13)) is handled this way and only when insert is OFF, Macros are allowed (MAC = 1) and provided the macro size (LEN) is less than or equal to FSiz. MFED's macro processing automagically recognizes and respects the INSERT state. That is, with INSERT OFF [Alt-S] overwrites whatever is in the field with 'Shawnee Mission'; with INSERT ON, the string is inserted at the current location as long as room permits. Macros are stored in a conventional string array. These can be hard coded in your application (eg Macro$(1) = "qwerty") or they can be read from a disk file. Again, note that you can name the array anything you wish so that a large application could alternately use several macro arrays so that one could hold city names, another could contain common account or reference numbers, another common zip codes or area codes and so forth. The Macro string array is a simple 35 element string array, referenced as follows: Elements 1 to 10 control the top alpha key macros: [Alt-Q] to [Alt-P] Elements 15 to 23 control those tied to middle row: [Alt-A] to [Alt-L] Elements 29 to 35 control the bottom row: [Alt-Z] to [Alt-M] Note that not all 35 elements are used, eg a string stored to Macro$(11) cannot be invoked. A Macro array can be qucikly filled from a disk file as follows: FOR x = 1 to 10 LINE INPUT #FilNo, Macro$(x) NEXT x FOR x = 15 to 23 LINE INPUT #FilNo, Macro$(x) NEXT x FOR x = 29 to 35 LINE INPUT #FilNo, Macro$(x) NEXT x CLOSE #FilNo Copyright (C) InfoSoft 1986-1989, 1990 If you do not wish to use macro processing, there are two ways to disallow it. The simplest is to only dimension Macro$() to 1. If the macro array is less than 35, MFed assumes that you do not want to use macros. Since the array is passed explicitly, it must be dimensioned to at least 1 even if you are not using macros so that an error is not encountered. You can temporarily or selectively suspend macro processing by setting MAC to 0. This causes MFed to ignore the macro processing code regardless of any assignments to Macro$() and Alt-keypresses. If the end user attempts to invoke a macro from a "blank" key, MFed emits a short, quiet click so that touch and fast typists can be warned that no macro was available. Note that you can arrange your code to even edit macros on the fly. By assigning this function to one of the function keys, all you need do is edit a temporary string and then place it in the array: CASE 13 ' assume F3 =edit macro CALL SaveScrn(2001) ' Save the main MFed screen CALL Windows(1, 1, 5, 25, 0, 0, 1, 78, "") LOCATE 24, 20 PRINT "Press key of Macro to edit" ' find out which one DO m$ = inkey$ LOOP UNTIL m$ > "" MacToEdit = ConvertKey(m$) ' write a function to check to ' see if it is a valid macro key ' return the scan code minus 15 ed$ = Macro$(MacToEdit) Mac = 0 ' turn off macros for now MCode = MFed(ed$, x, Macro$()) ' edit macro IF MCode = 0 THEN ' update/save if Enter hit Macro$(MacToEdit) = ed$ ' update macro array END IF Likewise, one of the function keys could be used to allow the user to signal to your application to save the current macro list to disk and yet another could be used to request a new set be loaded from disk. Copyright (C) InfoSoft 1986-1989, 1990 B. CLOCK Copyright (C) InfoSoft 1986 - 1990, 1991 I. Introduction CLOCK allows your program to provide an ongoing display of the time time WITHOUT the hassle, heartache or overhead of executing GOSUB statements to print TIME$. CLOCK works much the same as a DOS level TSR, that is, it installs itself in memory, latching onto to certain system interrupts to update a display of the current time as needed. The format of the display is " hh:mm:ss ?m " (12 hour format), with a trailing am or pm label. The problem with most similar time display programs quite simply is that they are not accurate! Over the long haul, a simple time keeping process is most likely to lose about .02 seconds each second. This may sound trivial or insignificant, but in a mere 5 minutes, the time display can be off as much as 2 or 3 seconds!! If your program is to run for hours on end, after a few hours, the time display will simply be inaccurate to a wholly unacceptable degree. To rectify this, CLOCK uses a secondary internal clock to es- timate the amount of time lost from 'True' system time and periodical- ly jumps ahead a second to adjust. The CLOCK in GLIB does not loose an entire second until over 8 hours have passed! During that time, CLOCK's time display consistently remained within a constant .5 to 1 second of the actual system time returned by TIME$. In fact, after 12 hours, CLOCK is incredibly still within 1 second! Over extremely long periods, even CLOCK will eventually vary from true time, so for applications that run continually, to adjust the time simply uninstall and immediately re install CLOCK. This will allow it to re-synch with the system time for another 8 to 10 hours. Accuracy is only part of the superiority of CLOCK. The friendly 12 hour-based display with the am/pm label provides a positive, easy to read display and the time display is fully configurable: it can be located or 'popped up' any where on the screen and in any color attribute. CLOCK will also emit a small, pleasant audible tone on the hour and on the half hour (even this is configurable). Since CLOCK does take of advantage of TSR-like programming techniques, it is installed rather than simply called, to invoke it. Likewise it MUST be uninstalled prior to your program termination. It is advised that you fully develop and write your program without CLOCK installed and only when it is fully debugged should you add CLOCK to your code. Copyright (C) InfoSoft 1986-1989, 1990 II. Syntax The syntax to implementing CLOCK is very simple: CALL CLOCK(row, col, attr, Func) row - The CRT line to display the time display at. col - The CRT column to display it at. attr - The color in attribute form to use in the display. Func - CLOCK function to perform: 0 = uninstall clock 1 = normal installation 2 = quiet installation (do not beep at half hour intervals.) Since CLOCK uses TSR type programming techniques, it must be uninstalled when you are done with it. This cannot be understated: CLOCK MUST BE UNINSTALLED BEFORE PROGRAM TERMINATION. This includes program crashes! In the event of a runtime error or crash, CLOCK must be uninstalled before your application exits to DOS. This means if you use ON ERROR type error traps, a call to uninstall CLOCK should be performed. Since CLOCK takes over some very key system interrupts, it is not advised that you use it with other TSR type programs or routines without a THOROUGH checking out of their compatibility. III. Programming Considerations CLOCK cannot be accidentally twice, CLOCK checks for such an attempt and precludes it. Should you wish to change the attributes or location of the display, perform two calls: the first to uninstall CLOCK then another to reinstall it with the new color or location (or both). CLOCK does no internal display preservation, so should you do an uninstall-install routine to change color or location, the last image of the first clock installation will remain unless you restore that portion of the screen or CLS or whatever. Copyright (C) InfoSoft 1986-1989, 1990 C. QCalc Copyright (C) InfoSoft 1987 - 1990, 1991 I. Introduction QCalc is one of the most powerful and useful callable subroutine in _any_ QB/BASCOM add on package. QCALC has every feature found in a cheap calculator, plus some. QCalc handles values ranging from -2.147 to +2.147 BILLION in either decimal or fixed point (as in dollar values). Such a full featured routine is great in and of itself, but being written entirely in assembler, QCalc takes _under_ 4k in your program! QCalc is completely self sufficient: all keyboard, video, bios and math calculations are _internal_ to it. There are no dependencies on other library routines you may or may not have available to you! Any sort of bookkeeping or number based QB/BASCOM application can benefit greatly from QCalc. QCalc is _not_ a TSR but it does remember the result from the last invocation within the same applica- tion! II. Calculator Operation When first invoked, QCalc will draw a representation of a small hand held calculator on the screen, complete with number keys and math operators. This true to life representation makes it ideal for accounting type systems where the user or operator is not necessarily a computer aficionado. QCalc invokes the Num-Lock key for even more convenience, and as numbers are pressed, the presses are replicated on the calculator display. Remember, all this power is available to you and your program with ONE simple CALL invocation. The default mode is Decimal Fixed Point entry since that is the most likely method for adding sales, calculating tax etc. Math Functions supported: + ... Addition - ... Subtraction * ... Multiplication / ... Division = ... Equals (the Enter key also acts as an implicit equal sign). Copyright (C) InfoSoft 1986-1989, 1990 Numeric Entry: In Fixed Point mode, the decimal can be used to fix the point. That is, entering 1 - 2 - 3 - 4 would result in a display of 1234.00, however, 1 - 2 - . - 3 - 4 would result in 12.34. Commas are not supported as entry characters in decimal mode, however they are displayed as needed. Other Calculator Operations: [Alt -] \ Changes the sign of the entry (like the '+/-' [Alt +] / key on a calculator). Note that these are the _top row_ plus and minus keys, not the grey ones. We would gladly use the grey one also (or instead), but the BIOS does not read them when used in combination with the Alt key. As operations are performed, and results displayed, QCalc simulates a physical calculator by retaining a display of the last 5 entries or results, ie a tape. [Esc], [Alt-Q] Abortive type exit - nothing returned [Alt-R] Alt-R, for RETURN, closes the calculator window and returns to your application, returning the last result shown on the calculator. [Alt-E], <E> E or Alt-E is for Clear Entry. Clears the number being entered or already entered. [Alt-C], <C> C or Alt-C is Clear All Clears the entry and history by scrolling the tape to clear. [Alt-D] Selects Decimal as the operating base. This is the default when first called. Should you switch to Fixed Point, QCALC will remember and come up in that mode. [Alt-F] Selects Fixed Point as the operating mode. BackSpace The backspace key is fully supported while entering digits. When used on a result, the backspace key acts as the Clear Entry key. Copyright (C) InfoSoft 1986-1989, 1990 Just as in a physical calculator, a result can be rolled over into an entry. Example: 4 * ; an entry 4 = ; 4*4 = ?? 16= ; 16 is a _result_ + ; tapping plus turns 16 into an _entry_ ! 16+ III Operation Tips QCalc can do any addition, multiplication, division or subtrac- tion as long as the result and both operands are within the +/- 2.147 BILLION range. Overflowing or underflowing this range will cause numbers to wrap: ie 2.147 BILLION plus 1 = - 2.147 BILLION and vice-versa. Percentages, as in a tax calculation, are easily handled with multiplication or division: Method 1 ( 2 step process): Tax rate of 5% on 34.65 34.65 * ; result of addition etc turned into entry .05 ; enter as "." + "0" + "5" = ; hit enter or equal 1.72 ; this is the 5% tax amount (a _result_ !) + ; turn result into entry 34.65 = ; add back in the taxable amount 36.37 ; Total amount due Note: For various reasons, the 5% amount, which is actually 1.728 is returned as 1.72 not rounded to 1.73. Method 2 (1 step process): 34.65 * ; result of addition etc turned into entry 1.05 ; enter as "1" - "." - "0" - "5" = ; hit enter or equal 36.38 ; this is the 5% tax amount (a _result_ !) Note: This is not only simpler and faster, it is more accurate! However many, many people do not understand that the total amount is going to be 100% of the taxable amount _plus_ 5%, ie 105% or (n * 1.05). Copyright (C) InfoSoft 1986-1989, 1990 To be able to isolate the tax amount, as might be needed on an itemized bill, just roll over the result into an entry and subtract the subtotal. Continuing from above, this is done like this: - ; roll result into a entry 34.64 ; deduct the subtotal 1.73 = ; the amount added to subtotal ie the tax. IV Syntax The immense power and functionality of QCalc is invoked with a mere 5 parameters that control virtually everything: Syntax: DECALRE FUNCTION QCalc&(Row%, Col%, Body%, Scrn%, Button%, Speed- Mode%) .. .. .. RetVal& = Calc(Row, Col, Body, Scrn, Button, SpeedMode) C. Parameters: RetVal& - QCalc will return to you the last _result_ value on the QCalc display. An entry value will not be returned. That is, entering '1+1=' will return 2. Simply entering 1 only, with no operation, will return the result of the last operation. This _must_ be a long integer. Row, Col - Denotes the upper left row, col coordinates for the calculator display. The size of the calculator display is 31 characters wide, 20 columns tall - roughly 1/3rd of the screen. QCalc is not only functional but it is very smart too: should you pass invalid coordinates for the row/col, it will adjust them so that the calculator display does not wrap. Three attribute values are passed to customize the calculator display specifically to your needs. QCalc will use the correct display mode for mono vs color/EGA/VGA displays, but does no second guessing on the attributes you pass. Be sure that the attributes you choose are appropriate for the display present. EGA's must be in 25 row mode or QCalc simply exits gracefully. Copyright (C) InfoSoft 1986-1989, 1990 Body - The color to use in the calculator body. This is the predominant color used. Screen - The color to use on the 5 line calculator display. Since the end user will be focusing on this, it should be an easy to read color, however certain attributes can replicate a LCD appearance to make the display even more realistic. Button - This color is used a very little, only to simulate button presses and the like. Since it is used on the calculator body, some very interesting effects can be created using totally different background colors or the same so that just the key text changes. SpeedMode - This allows the programmer or end user to tailor a portion of the operation characteristics. When a numeric key (0-9), E or C is pressed, the appropriate display is briefly recolored with the Button Color and a tone sounds. The SpeedMode parameter allows you to set the duration for the tone in clock ticks (1 / 18.2 seconds (we suggest 2). This time is not system dependant so it makes no difference if QCALC is called on a 386 or a 8088 machine. However, you may want to turn off the beep tone or speed it up or slow it down - the SpeedMode parameter affords you this option. Additionally, after the beep, QCALC purges the keyboard buffer of type ahead characters, which is also disabled with the SpeedMode parameter. SpeedModes 0 to 4 do not purge the type ahead buffer and represent in clock ticks, how long the tone should sound in the beep/button recolor operation. Zero is the shortest, with the beep/recolor disabled, four is the longest with it taking about 1/2 second (twice as long as a BASIC or DOS Error BEEP !). For reference, we recommend 2. SpeedModes 5 to 9 represent the same clock tick count as 0 to 4, that is, SpeedMode 5 disables the beep with the difference being that SpeedMode 5 to 9 DO purge the type ahead buffer. So SpeedMode 7 provides the same display effect as 2 with the difference being that 7 will eat up any keys waiting in the keyboard buffer. Copyright (C) InfoSoft 1986-1989, 1990 V. Programming Considerations QCalc returns the last _result_ on the display to your program. This means that in a book work type program, you could pop up QCalc to allow the user to add up sales or paid outs, and when they leave QCalc via [Alt-R], QCalc will return the last result shown on the calculator display! Your program could then automagically insert that value on the screen and the proper variable! If the user leaves QCalc via [Esc] or [Alt-Q], QCalc simply 'pops down' and does not attempt to return anything. You can force a return to your program by simply setting up a loop until QCalc DOES return a value. This maybe helpful in cases where the calculator covers up some of the entry items on the screen forcing the user to occasionally 'pop down' to read more info. Ex: DO UNTIL RetVal& <> 0 RetVal& = QCalc(row, col, attrs, attrb, attrf, speed) IF RetVal& = 0 ' no return LOCATE 23, 10 PRINT "Return Required - Press any key for calculator." ELSE EXIT DO ' return was okay get outta LOOP END IF x$=INPUT$(1) ' get a key, any key LOCATE 23,10 ' cover over msg PRINT SPACE$(46) LOOP NOTE! NOTE! NOTE! QCalc returns a _LONG_ integer. These are 32 bits and require that your receiving variable must be an _LONG_integer. Attempting to assign the result to an integer _will_ result in OVERFLOW. The return is in decimal mode. If your application is using fixed point numerics, simply divide the return by 100. Notes Within the same program (ie without CHAINing, RUNning or spawning a new module), QCalc retains the display of the last entry or result. Theoretically, this allows the user to pop up QCalc, add up some numbers, pop down to get more info from the screen and return to right where they were - previously entered data is _not_ lost! It is also important to note that second and third and fourth calls to QCalc do _not_ have to be at the same location for QCalc to pop up the same display! Copyright (C) InfoSoft 1986-1989, 1990 QCalc automagically engages the Num Lock key when invoked and retores it when exiting. Since we are not afflicted with one of the 'enhanced' 10x key keyboards, we are not yet sure what this does with them. However, it is in deference to them and the nonspatial -kine- sthetic layout that no function keys are used. We hope you enjoy QCalc and find it's vast power and incredible ease of use to be of benefit in your program. QCalc is completely ported to 'C' language so that should you learn 'C' or are already somewhat multi lingual, this invaluable tool can 'go with you' and your programming endeavors. Copyright (C) InfoSoft 1986-1989, 1990 D. FlexMenu Copyright InfoSoft 1988 - 1990, 1991 Flexmenu is a snappy, full featured, multi purpose menu-select subprogram that supports a plethora of features with a minimum of setup or parameters to manage. Many of the programs we write require easy to use and intuitive menus for novices, yet navigation still needs to be flexible enough so as not to frustrate experts. We routinely use FlexMenu in these situations because it fits all these needs and more. Syntax: item = MenuChoice% (Menu$(), Trow%, LCol%, Nattr%, Hattr%,_ title$, Mark%(), XtdChc%) Using the list of items in Menu$(), Flexmenu displays a box on the screen at the location specified by TRow, LCol. FlexMenu auto- matically calculates the rest of the coordinates (length and width). If the number of choices is greater than 14, the box is truncated to hold the first 14, with the rest being displayed thru the use of the arrow keys. When this is the case, and selections are off the screen either above or below, up and/or down arrows (ASCII 24 and 25) will be located on the right border. Additionally, FlexMenu displays a relative scroll bar along the side of the menu, showing where in the list the highlighted selection resides. The list of choices or menu items is in the color attribute specified by Nattr (Normal ATTRibute), and the current selection is highlighted in color HAttr. An optional title is centered across the top of the box. FlexMenu will elegantly handle as many choices as you can fit into string space. Theoretically, this is 65535, but unless your program has no code, there is little chance this much can be allocated. As we mentioned, for appearances, the box is never larger than 14 selec- tions. Navigation is intuitively managed with the arrow keys (Up and Down), Pg Up, Pg Dn, Home and End - all doing what you would expect. Additionally, FlexMenu responds to a alpha search - press "A" will locate and go to (but not select) the first item after our current item starting with "A" or "a". Pressing [Enter] returns to your code the index number of the item pressed. If we are on item 1527, 'item' will be set to 1527. If you prefer your FlexMenu with a background 3-D shadow, and most of us do, simply place a call to BShadow ( "CALL BShadow(1)" ) before- hand - this makes all Boxes calls automatically shadowed. We would find FlexMenu highly useful if that was all it did but it does much, MUCH more: Copyright (C) InfoSoft 1986-1989, 1990 1) Flexmenu will automatically center the display (which we use almost exclusively) by setting both TRow and LCol to -1. This pre- vents you from having to twiddle and map out where the center is. 2) If you are performing list processing, FlexMenu will allow you to 'feed' a variable representing the last item selected. That is, if on the last call to FlexMenu, the user selected item 127, we can initialize the next call to FlexMenu to allow that the last item selected is highlighted on the screen! Since this is a modification from the initial releases of FlexMenu, and is more or less an ancil- lary function, this variable is passed and defined in a COMMON SHARED block. If you have no need for this feature, simply do not define the common block. To use this feature, define a common block as follows: COMMON SHARED /FlexVars/ FlexFeed%, FlexAll$ When FlexFeed is initialized to a value within the range of the menu passed, FlexMenu will be scrolled so that menu selection cor- responding to it is on the display. The second COMMON variable controls a Mark All function covered later. 3) It responds to extended keystrokes. If we highlight item 156, and press enter, item is set to 156. If we press [Alt-Q] instead, item is still set to 156, but the extended choice parameter (XtdChc) is set to 16 (the ASCII code for Alt-Q). This allows us to manage multiple functions from one menu. For example, we might use DIRA to load a string array and FlexMenu to display the file names and from that, [Alt-D] might delete the chosen file, but [Alt-L] might list it. Then via a SELECT CASE statement the desired functions can be swiftly carried out. To filter out unwanted extended choices, simply place the call to FlexMenu in a DO or WHILE loop as shown in the following example. Copyright (C) InfoSoft 1986-1989, 1990 done = 0 DO item = MenuChoice(menu$(), -1, -1, 78, 3, "Demo", Mark(), XtdChc) SELECT CASE XtdChc CASE 1, 2, 3, 4 GOSUB MoreChoices CASE 12, 14, 15 GOSUB SomeStuff CASE 16 GOSUB KillFile CASE 23 ' get another selection CLS item = MenuChoice(f$(), -1, -1, 78, 3, "Demo", Mark(), XC) IF (XC <> 27) AND (Item > 0 ) THEN GOSUB GoodStuff END IF CLS ' clear for next loop CASE 27 ' Escape done = 1 SYSTEM CASE 18 ' Alt - Q done = 1 CASE ELSE 'unsupported functions END SELECT LOOP UNTIL done In this type of construction, we limit the methods of ending the program to the 2 we are prepared to handle. In this way, the display (Menu$()) can represent either a list of things to act upon such as file names or a list of actions or a menu itself! Creativity in nesting allows virtually unlimited possibilities -- we have one program that manages some 40,000 items and menu functions in 5 Flex- Menu calls. The novice user is always interacting with FlexMenu, never DOS or the engine of the program. There is even MORE! Copyright (C) InfoSoft 1986-1989, 1990 4) FlexMenu optionally supports a "Mark Mode" or multiple select function. By setting XtdChc to non zero upon entry, you enable mark mode where pressing the TAB, or SPACEBAR toggles a mark for that item. The number of marks allowed is set by XtdChc, setting it to 10 allows 10 - and only 10 - items to be marked; set to 5, only 5 would be allowed and so forth. Marked items are tagged with bracketing " " and " " (ASCII 174 and 175) characters (only on the display! FlexMenu will not alter your menu array!), and all the other features remain in effect - alpha search, navigation and extended keyboard selection. To accomplish this, you must pass an integer array that is of the same size as your main selection string array. FlexMenu will use this as a set of pointers indicating which items are Marked: if elements 5, 6, 10 and 37 are set (non zero) upon exiting, then the user selected or marked selections 5, 6, 10 and 37 from the menu. 'Item' will STILL return as the highlighted or current item when ENTER or an extended key is pressed - it is up to you to use it or not. If the Mark integer array is not the same size as the string array of choices, Mark Mode is disabled. However, if mark mode is NOT desired, enter FlexMenu with XtdChc set to 0 and/or dimension Mark() to a single element. You will recall that the COMMON block contains a vaiable names "FlexAll$". If defined, when the user presses the key defined by you as FlexAll$, ALL the items in the list are MARKED. This feature respects the value of the maximum MARKS allowed by XtdChc, so this feature is only available when all XtdChc=UBOUND(Menu$), ie all items in the list can be marked. For example to define Alt-Q as the Mark All key, FlexAll$ = CHR$(0) + CHR$(16) ' Extended key code for Alt-Q If/when the user preses Alt-Q all menu items will be marked. 5) FlexMenu will also "remember" previous marks upon subsequent calls unless you REDIM the MARK array. FlexMenu examines Mark() as it is setting up and treats non zero elements as marks. That is, upon initializing it does not assume that it is the first time. Using this, you can "suggest" selections by setting the corresponding Mark() element before calling FlexMenu - the user can of course toggle it off, but in cyclical applications, the user need not remark previous selections. We use FlexMenu almost exclusively in our menu driven applica- tions, since it is powerful, fast, relatively small and has many features and have found it to meet most every need. NOTE: FlexMenu requires the QPrint, Scroll, QPrintV, Painter, StrLen and Boxes object modules. Copyright (C) InfoSoft 1986-1989, 1990 E. StatLine Copyright (C) InfoSoft 1988 - 1990, 1991 I. Overview StatLin is the name of the object file containing several rou- tines or primitives that aid you in displaying and/or controlling a one or two row status line. Collectively, we will refer to them as StatLine. These routines are: CLX - Clear the screen except for the status line area. SetBline - Set the bottom line of the non status line area of the screen. Similar in function to the BASIC WINDOW statment. PrintStatL - Prints all or part of an array designated for the status line. II. Operation The default bottom line of a screen using StatLine procedures is row 23, or a 2 row status line as used in the demo. You can set this to more or less depending on your needs, thus allowing you to use even 5 lines for the status area or even simulating a split screen effect. If you use more than 1 or 2 rows for the status line however, you will need to maintain those above 24 as PrintStatL will only print to line 24 and/or 25). Beyond that limitation, these routines allow for printing and updating a status line, and clearing the non status line portion of the screen. Copyright (C) InfoSoft 1986-1989, 1990 III. Functions Name: SetBVLine Type: SUB Level: ASM Syntax: CALL SetBVLine(x) As mentioned, the default bottom line of a screen using StatLine procedures is row 23, or a 2 row status line as used in the demo. If you wish to reserve more or less area than that, SetBVLine will allow you to Set the Bottom Video Line to be respected by PrintStatL and CLX. Note that if you set it to 23, a call to CLX will ONLY clear lines 1 to 23, saving the bottom two status lines and preventing you from having to redraw them. However, CLS will still clear the entire screen. Name: CLX Type: SUB Level: ASM Syntax: CALL CLX This may also be called or invoked as ClrScrn This simply clears the non status line portion of the screen. Where CLS would clear all 25 rows of video, CLX respects the default bottom video line of 22 or whatever you have set it to using Set- BVLine. Like BASIC's native CLS statement, this also relocates the cursor location to 1,1 by performing a call to the actual BASIC RTL (Run Time Library) so that not only the cursor is physically relocated, but the internal cursor location variables held by the QB RTL are reset allowing CSRLIN and POS(0) as well as PRINT to act as expected. That is, an explicit LOCATE 1,1 is not needed to complete the CLX/ClrScrn function. Name: PrintStatL Type: SUB Level: ASM Syntax: CALL PrintStatL(StatMsg(1), Action, Attr) This prints all or part of a 2 element fixed length 80 character string array to the status line area of the screen in the designted color. Copyright (C) InfoSoft 1986-1989, 1990 1. To pass a fixed length string array to a CALLed ASM sub, you must hide it in a TYPE structure by setting up a user defined TYPE that is simply a single 80 character string. Ex: TYPE struct ' tell QB what it looks like fls AS STRING * 80 END TYPE DIM StatMsg(2) AS struct ' order one 2. Also to pass a TYPE structure to an ASM routine, you must DECLARE it using the keyword ANY. So the DECALRE for PrintStatL would be: DECALRE SUB PrtSL(MsgArry AS ANY, Action%, Attr%) 3. At this point, we may fill the array with messages. Feel free to use LSET or RSET with the array to justify strings. Example: StatMsg(1).fls = " Time: " + TIME$ + " Temp: "+ degree$ + msg$ StatMsg(2).fls = " Code: " + Information$ 4. Finally invoke it with the desired action code and attribute: CALL PrtSL(StatMsg(1), 0, Attr) ActionCode tells PrtSl what action to perform: 0 = Print/Update both lines 24 and 25 1 = Print/update line 24 only 2 = Print/update line 25 only In more sophisticated applications, you can define more than 2 elements for the message array and selectively update higher offsets in the array. For instance, if your program has 5 main function levels, you might need 5 different status line displays. Using a 2 line display means we need 10 elements so, DIM StatMsg(10) AS struct ' set up 5 status line SETS When we are working on the Main or top level we invoke elements 1 and 2 to print to lines 24 and 25 as normal (above). For subsequent levels we pass the element to be mapped or printed to line 24, the second activity level would be: Copyright (C) InfoSoft 1986-1989, 1990 CALL PrtSL(StatMsg(3), 0, Attr) ' element 3 goes to 24, 4 to line 25 ' level 3: CALL PrtSL(StatMsg(5), 0, Attr) ' and so on to level 5: CALL PrtSL(StatMsg(9), 0, Attr) Of course, your use of OPTION BASE 0 means you subtract one from the element passed. Notes: Being a fixed length string, a very large number of status line messages can be stored in your fixed length sting array, but be sure to use the /ah switch if the array is to be more than 64k. Also, large fixed length string arrays should ALWAYS be even multiples of 2. This is so that if and when they span a segment boundary, the segment boundary will break at the start of an element and NOT in the middle of a string or structure. QB inititializes a fixed length string to NULLs, NOT SPACES, so displaying a message array that you have not modified, may result in unexpected results. PrintStatL expects a 2 line status area, so to use only line 25, your message array would still have to be 2 elements per "level", but every other one would be blank or NULL. MsgArry(1) always maps to line 24, as does 3, 5, 7, 9 etc. These would be blank, but 2, 4, 6, 8 etc would be filled for mapping to line 25 when you want to use only line 25. Note that SetBVLine has no effect on PrintStatL only on CLX. PrintStatL expects the message array to be a 80 character string array - if you dimension it to a smaller number the memory contents immediately following the arry will be printed. Ex: if you DIM it to STRING * 60 (rather than 80), line 24 would display the first element PLUS the first 20 characters of the second, and the bottom line would display the next 40 characters of the second element PLUS what ever garbage is in the next 40 bytes of memory. Copyright (C) InfoSoft 1986-1989, 1990 F. DialogBox Copyright (C) InfoSoft 1989 - 1990, 1991 I. Overview If you've ever carefully looked at the code for most finished programs of any size, you can often be amazed at the amount of code that is dedicated simply to validating user I/O. Be it precluding invalid filenames, verfying an input character or reacting to an error situation, vast portions of code (and naturally, coding time) in 'bullet proof' programs end up dedicated to this. Naturally if you use one menuing method and one or two user I/O routines and CALL or GOSUB to them, your program size could be con- siderably reduced. That is what we did on one application: all select-from-menu inputs were replaced by FlexMenu(qv), all extended string input was replaced by MFed, and all program-to-user messages (like "Overwrite File?" "File Does not exist!" etc) with the likes of PGetCh, GetCh and WINDOWS were replaced by Boxes. With little other code structure changes, the program shrunk 17% ! DialogBox is an SAA style input box designed loosely after the ubiquitous dialog boxes found in QB, QBX, TC and QC as well as other integerated applications (MICROSOFT WINDOWS...). DialogBox allows you a simple, compact, fast, all-pupose method of communicating error conditions and/or choices to the end user, and get a delimited re- sponse from them. The functionality of DialogBox comes from a minimum of parameters needing to be passed. You pass only a few strings, and the routine automatically determines the size of the box. Copyright (C) InfoSoft 1986-1989, 1990 II Parameters Name: DialogBox Type: FUNCTION Syntax: ret$ = DialogBox$(msg$, prompt$, okay$) Msg$ - Typically, this would be used to explain or describe a problem or error, or to pose the premise of a question you wish to ask. Example: "File Not Found" "Error writing to disk" "Printer not online" "Delete all files" Prompt$ - This might typically explain the list of possible actions or choices or expand on the Msg$ displayed. Examples: "Abort or Retry?" "Swap Disks, Retry" "Fail or Retry" "Yes, No or Cancel" Okay$ - Tells DialogBox what input is ok. This list is displayed in the DialogBox on the line below prompt$. Additionally, if Okay$ is NULL ( "" ), then DialogBox will accept any key press as an act of acknowledgment by the user and "< OK >" is displayed where the OK list normally would be. This list must be in upper case see GetCh. ret$ - Returns to your calling program the upper case character pressed from the okay list that allowed the user to exit DialogBox. Copyright (C) InfoSoft 1986-1989, 1990 Syntax example: msg$ = "Delete marked Files?" prompt$ = "Yes, No or Cancel" okay$ = "YNC" ret$ = " " OutPut: (this may be distorted depending on your printer) Delete Marked Files? Yes, No or Cancel <Y> <N> <C> The entire box is cenetered horizontally and vertically on the display, all text is centered within the box, a single line frame border is used and the color attribute is black on white reverse video. As mentioned, the left and right borders of the box are calculated internally to DialogBox so you need not mess with loca- tions. DialogBox does NOT do any screen saving and it does not check for string length errors: a msg$ length of more than 78 characters will surely cause unexpected and/or unknown results. The defaults used in DialogBox (location, color etc) are designed to be as SAA-like as possible, to make invoking it as easy as possible and as always, lightening fast. However, the defaults can be changed either for current or subsequent calls. In the example, you will note that DialogBox parses the passed okay$ and displays them individually within brackets. If the list of okay responses is more than 5 however, or both the message and prompt are abnormally short, it will simply list them: QWERTY is simply centered. Copyright (C) InfoSoft 1986-1989, 1990 III Altering DialogBox defaults As is, the DialogBox defaults eliminate many decisions such as colors to use depending on the monitor type, where to locate it and so forth, and provide a SAA appearance to the program. However some people are going to just die if they can't use colors with it or locate it somewhere else (in fact, re-locating the box may be required in some cases where something relevant to the message gets covered up by it). So, should you want to change any of these, we have devised a sub program to set user defined defaults: Name: DBoxSetUDef Type: SUB CALL DBoxSetUDef(TRow, LCol, Frame, BAttr) TRow - The top row for DialogBox LCol - The left column for the location Frame - The style of frame to be used (see BOXES for a complete list) BAttr - The new default color to use Once called, DBoxSetUDef sets a flag to instruct DialogBox that user defined parameters are in effect and to use them. These para- meters, in fact become the new defaults until you reset them or clear them. This allows you to position and color the box any way you like. Note that you only need to set the Top Row and Left Column: DialogBox will still calculate the bottom and right box frames based on the length of the strings. You cannot make the box bigger and locations are NOT verified: Setting the top row to 52 will have unwanted re- sults. Note that using DBoxSetUDef means that ALL the parameters are changed. Name: DBoxClrUDef Type: SUB CALL DBoxClrUDef This merely clears any user defined parameters from DialogBox and allows it to once again execute with default parameters. Copyright (C) InfoSoft 1986-1989, 1990 Name: DBoxSound Type: SUB CALL DBoxSound(SFlag, Frequency, Duration) Since I often find myself sounding the speaker just as I pop up a DialogBox, we have gone ahead and built in sound capability. The default tone for this is the equivalent of using GLib's SpeakerSound routine: CALL SpkrSnd(1200, 1) The default for the sound is ON with a frequency of 1200 and a duration of 1. To alter any of these, simply use DBoxSound. Setting SFlag to 0 turns the sound off, 1 turns it on. To alter the default tone, call DBoxSound with SFlag set to one and frequency and duration set to the desired values. IV Usage One way we have used this was to have all possible program messages, prompts etc stored in an Fixed length string array and when needed, we simply called a DBox handler with an ActionCode. This handler then copied the strings to a normal array, saved the screen image, called DialogBox, erased the temp array, restored the screen and returned the selected character to the main program. Alternatively, a larger program that could not spare the memory, left all such messages in a random file. The box handler then fetched the necessary text from the file (keyed on the ActionCode) into simple strings, called DialogBox and then returned the input. Using such techinques, the main program need only determine error conditions, and act on reponses - all the I/O with the user is relagated to a sub- program. There is a little less flash and dazzle to DialogBox than emulat- ing the same with MFed and WINDOWS but in very large applications, where code space or development time is critical, rather than spending time with setting up actions and such DialogBox can provide a uniform, straight forward very fast approach to simple prompted user I/O. Copyright (C) InfoSoft 1986-1989, 1990