Programmer 7500

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

/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / HAMRADIO / KI6LO521.ZIP / ADDENDUM.DOC next >

Wrap

Text File | 1990-05-01 | 18.3 KB | 357 lines

Version 5.2x User Manual Addendum CHANGES / ADDITIONS TO PREVIOUS V5.20 The following are a list of changes and/or addito\ions made to version 5.20 since its release in January 1990. Some of these items were not ready for release in verison 5.20 and others were cleanup or adjustments to existing features. Each is noted as to whether it was a change or addition, also where in the v5.2 manual the topic is found. 1) Program name change All pages - Change All filenames shown as LOG52.EXE should be changed to LOG521.EXE All filenames shown as LOG52.OVL should be changed to LOG521.OVL 2) DATA FIELD ENTRY ENABLED TOGGLE FEATURE page 20 - Addition - Data Input Field Status Selection Page page 53 - Addition - Menu option "SET ACTIVE FIELD STATUS" Some users were requiring that some of the non-required fields on the Data Input form be disabled so it would speed up data entry in their particular case. I decided to enable the user to turn off (or on) any or all of the non-required fields in the log file. All fields in the top box on the Data Entry form ARE required and can't be turned off. During initialization (or when v5.21 is first started and the USER_LOG.CFG configuration file from v5.20 is detected), a screen like the one shown below is displayed. Perform the functions as called out in the accompanying text to toggle the fields ON to OFF or vice versa. If a field is toggled to OFF when the ESCAPE key is pressed, the 'OFF' label will appear in the area on the DATA INPUT form where you would normally enter input data. It will appear there everytime you select the ADD DATA option until you reset the field to the ON status. To reset any or all fields, select the "SET ACTIVE FIELD STATUS" option on the UPDATE USER DATA MENU from the FILE MAINTENANCE MENU. Perform the required actions as before, saving with ESCAPE when done. ***************************** DATA ENTRY FIELD STATUS +-------------------------+ | 1 - NAME .......... ON | * All default to ON | 2 - CITY .......... ON | | 3 - STATE ......... ON | | 4 - COUNTRY ....... ON | | 5 - CQ ZONE ....... ON | | 6 - ITU ZONE ...... ON | | 7 - REPORT SENT ... ON | | 8 - REPORT RECV ... ON | | 9 - ANTENNA ....... ON | | A - QSL SENT ...... ON | | B - QSL RECVD ..... ON | | C - MISC FIELD .... ON | +-------------------------+ The window above shows the current status for ALLOWING data input to the non-required fields of a log file. Pressing the NUMBER or LETTER associated with the fieldname will toggle the ACTIVE status of the field. If the status shows 'ON', you will be able to enter data in that field when using the DATA INPUT form in the ADD QSO option. If 'OFF' is shown, the field will be disable till you reset it to 'ON'. Set fields to desired status and press ESCAPE to save conditions and EXIT to previous menu. NOTE : Default is all fields set to 'ON'. *************************** 3) 'HOTKEYS' OPTIONS - FUNCTION KEYS AND WHAT THEY DO page 24 - Addition F7:CALL - QUICK CALLSIGN CHECKING Realizing that the ability to do a fast check for a callsign on-the-fly was needed and had been noted by several v5.20 users, I added this option for use in all areas of the program EXCEPT while using the 'browse' function in the UPDATE LOG or QUERY modes. Pressing F7 will give you a prompt as shown below. You will enter the callsign to find (up to 12 characters). ENTER CALLSIGN TO FIND (12 CHR MAX - <CR only> ABORTS) : ___________ Please note : If you enter only part of a callsign, say "VK4" or "WB0" you will get ALL calls that start with the partial callsign. If you had 20 contacts with VK4 stations and 5 of them were to VK4AA, entering VK4 would find 20 contacts, while entering VK4AA would find only 5. This is handy to see if you may have worked a prefix or area already. If any entries are found, a window is opened on top of whatever you doing and ALL the matching QSO's are shown in the window, listing the first 9 characters of the CALLSIGN, the date-time-freq-mode of the QSO, the operators name (if any), QSL information and the country. If more a definitive 'look' at any particular QSO data is required, move the highlighted line to the QSO in question and press RETURN. Another window is opened and all data for the QSO is shown along with any COMMENTS. Press any key and the second window closes and you are back at the list window. Select another or press ESCAPE to return to the activity at hand before F7 was pressed. You may press F7 again for another callsign or group of callsigns. PLEASE NOTE : This is only a 'Viewing' option - no printing done here. page 26 - Change ALT-T key - TOGGLE THE AUTO DATE/TIME STAMPING DURING ADD QSO'S The label for stating the status of the AUTOTIME feature was moved from the right side of the menu to below the menu. It also shows the status for both ON and OFF. The operation is the same as before. page 27 - Change ALT-U - TOGGLE CALLSIGN DUPING OPTION ON / OFF The label for stating the status of the DUPING feature was moved from the right side of the menu to below the menu. It also shows the status for both ON, OFF, FULL or QUICK (see below). page 28 - Addition ALT-Y - TOGGLE DUPING MODE - FULL / QUICK In order to allow faster duping without data retrival and copying as done in v5.20, another DUPING mode was added for v5.21. This mode called QUICK MODE (the original DUPING mode was renamed FULL MODE) will allow the entry to be duped and you are warned if another call of the same exact type (not like the F7 partial callsign entry above) is found. If one is found, the following message is shown: +----------------------------------------------------------+ | DUPE CALL - Press RETURN to keep, Any other for NEW call | +----------------------------------------------------------+ Press RETURN, the callsign is kept and the data entry process continues. Press any other key and the callsign is removed from the input block and you are ready for another callsign entry. For the FULL DUPING MODE, it works the same as duping in v5.20 except if you select to not search for more matching entries, the current callsign is kept and the entry process continues on to the date field. page 31 - Change Example of Data Entry Form The below diagram shows the new DUPING mode label placement. The status of the DUPING is shown at the 'FULL' location. Pressing ALT-Y will toggle the DUPING MODE while DUPING is ON. It has no effect while DUPING is OFF. F1:HELP F2:TONE F3:KEYS F4:TIME F5:PRFX F6:MODE F7:CALL F8:DBF ADD +--------------------------------------------------------------------+ | QSO INFORMATION | +--------------------------------------------------------------------+ | Callsign : [ ] Duping : FULL (Alt-Y) | | | | Date (M/D/Y) : [12/10/89] Time (Zulu) : [1930] | | | | Frequency : [ 0.000 Mhz] Mode : [SSB] | | | +--------------------------------------------------------------------+ page 41 - Change CONNECTING THE INDIVIDUAL CONDITION STATEMENTS Once the field name, compare symbol and target value have been entered, you will be shown another selection window asking if you want to 'connect' this statement to another logically. Remember the pre- vious example where we used an 'AND' and an 'OR' to connect statements. You will be shown this window: +-------------------------------------------------------------------+ | Previous condition AND this condition must be TRUE for match | | Previous condition AND NOT this condition must be TRUE for match | | Previous condition OR this condition must be TRUE for match | | Previous condition OR NOT this condition must be TRUE for match | | No more entries needed in this condition set | +-------------------------------------------------------------------+ Now there are 5 choice here instead of 3. The menu has been increased in size and text to help make the decision about which one to use. The process of 'connecting' the statements together is the same as in v5.20. ****************************************************** Additional information and clarification on the use of QUERYING THE LOGBOOK FILES Several users have called stating that the new v5.2x query system seems to be slower than the v5.11 query interface. Well, it is if you use the data access time as the only reference to performance improvement. In the following text, I will explain why the the new in- terface seems slower and what can be done to make it perform to the maximum capability. To BUILD or not to BUILD : In v5.2x, you have the capability to build a 'filtering' string or condition statement which could be saved to a disk file for later recall. The condition statement could be a simple comparison or an elaborate 'filter' to ignore all but a specific few records. Whether to build a string or not is up to the user. If it is not built, then the program will react in 1 of 2 ways. Condition #1 - If entering the QUERY menu from the MAIN Menu and having not built a previous condition statement once in the QUERY menu, if the VIEW option is selected then ALL records will be shown on the screen. Since there is no condition to limit the access to the records, all present records are displayed in the ordering you select from the 'INDEX BY .... ?' menu. Condition #2 - If a condition statement has been previously built and another is NOT built prior to VIEWING and if the statement pre- viously built wasn't 'ALL' (see manual for meaning of 'ALL'), then the display will be limited to those records that 'pass-thru' the filter (i.e. match the condition statement). I would strongly advise that for casual 'browsing' (VIEWING) that the condition statement be 'ALL' if one is to be built. Also that the INDEXING order be that of a natural logbook (i.e. chronologically by DATE and TIME), since this will help group all daily contact and will correspond with your recollection of events and QSO's easier. *************************** Remember that F7 is also available for FAST checking of callsigns in log file. *************************** Also be aware that if the condition statement is too limiting (many facets to match) that the system will take longer since it must check each record field against the matching statement for any pos- sible match. In a log of several thousand QSO's, you could setup a condition that would possibly take several minutes to search through all the records. To avoid this type of delayed searching, select the index that closest matches the type of data you will be looking for. Select 'INDEXED by COUNTRY' if you are going to be limiting your found records by country name. If there is not close index or if you are unsure, select NO index and let the log go in natural order. Using the F3 FIND key : Using the F3 find key in the wrong place at the wrong time will not hurt anything, but it could eat up a lot of valuable computer time. For instance, if you are searching for all records that have the country equal to, say ENGLAND, and pressed F3 for a quick find of a callsign that is not in ENGLAND, then some strange things can happen. Let me clarify the last statement. The strange things are a result of you forcing the program to try and do something it is easily capable of doing, but during this stage of the game, it is somewhat taxing on the program's performance. What could possibly happen is this. If the program finds the callsign, it will go to that record position in the log file, put the QSO data on the query display screen at the line where the highlighted box was at when the quick find was requested (F3 pressed) and then continue from the callsign matching record and display records that originally matched the condition statement in use, till the screen is full or the end of the log file if found, which ever comes first. If you have several thousand records and just searched through and filled the screen, which could take a little while depending on the complexity of the condition statement, the program has to now research the log file filling the screen again. This is a repeat of time already used and hence a degradation of system performance. By limiting the use of the F3 key, whose originally intent was a quick way to jump around in a 'full' browse (remember 'ALL'), you can eliminate wasted time and speed up performance. Also, if the record in which the callsign was found does NOT match the condition statement, then when the display is scrolled to cause that record to leave the displayed area, scrolling back to that record will cause THAT callsign record data to NOT be displayed. It doesn't match so therefore it is not displayed. It is displayed the first time simply because we forced it to be displayed by using the F3 FIND function. Once it is removed from the screen, it is not displayed again unless you repeat the F3 action. To summarize, a few key points and some Do's/Don'ts are listed below: 1) Use 'ALL' as the condition statement for casual browsing. 2) A complex condition statement will most likely cause the sys- tem to slow down in searching since more fields are involved in the search. With a slow system and many entries, the system could effectively slow to a crawl. 3) If the system seems to be stuck or not responding as you think it should, DO NOT keep banging on the keyboard. Instead let the system 'catch up' to a full page of records on screen or allow it to come to a point where it is waiting on you, then press ESCAPE to leave that browse and rethink your query statements. Are they too limiting for the expected speed and performance. 4) Selecting an INDEX other than DATE and TIME (natural order) will cause the search time to increase. You may avoid this by matching, as close as possible, the INDEX key field to the data being searched for. 5) When 'browsing' and searching for callsigns, etc. with F3, select the DATE/TIME index for a log file and the PREFIX index order for the DX INFO file, and have the condition statement set to 'ALL'. This will give the maximum speed performance of your system. 6) Larger logs take longer to search and if a complex condition statement is applied, this time could be several minutes, depending on the log size and what you are looking for. 7) For maximum time use, do most of your querying while not operating since query searches can be quite time consuming. Use F7 for on-the-fly entry checks. 8) Whenever searching for matching keywords in the COMMENTS field, be prepared to allow a larger amount of time since each word or phrase in each COMMENTS field must be compared to the condition statement. 9) Don't expect a 4 Mhz 8088 machine with a slow hard disk to be a optimum performer in a large query situation. Any machine will only do its best. A 4mhz 8088 can't possible give the same searching performance as a 20mhz 80286 can! 10) Experiment with different query conditions and record the results for later comparisons. You will discover what situations to avoid with your system's setup. Version 5.2x query interface is very powerful. It will allow you to find almost any data configuration you will need in ham radio logging. The performance level is many times that of v5.11 and hence there may be a few situations in which the previous version has the edge when it comes to speed. But don't be fooled in to thinking that because v5.11 does something faster that it was a better program. Many, many hours of design and testing/tweaking have gone into v5.2x and I hope that everyone can master the query interface to obtain the maximum performance from it. It requires a small amount of experience to really benefit from it. Besides it never hurts to learn something new. If you still are having problems with the performance expectations, send me a copy of you log file and a letter of what you are trying to do. I will take a look at it and get back to you with help. 73's Gene KI6LO