home *** CD-ROM | disk | FTP | other *** search
/ Crawly Crypt Collection 1 / crawlyvol1.bin / telecomm / kmterm18 / km_term.bug < prev    next >
Text File  |  1993-01-20  |  4KB  |  83 lines
  1. KM_TERM Known Bugs :-
  2. =====================
  3.  
  4. 1. Medium RES fonts loaded by e.g. Harlekin or FONTSEL.ACC work 
  5. fine on their own but cause KM_TERM to crash when QuickST3 is 
  6. installed.
  7. --> This appears to be a bug in QuickST3 concerning the GEMDOS 
  8. 'CCONWS' call. It doesn't occur with Turbo ST or QuickST 2.
  9.  
  10. If you wish to use an alternative screen font with KM_TERM in 
  11. medium RES with QuickST3 installed, use the custom font handling 
  12. incorporated in the QuickST customiser accessory or better still 
  13. use QUICKSTC.PRG (v2.1)
  14.  
  15. ----------------------------------------------------------------
  16.  
  17. 2. On exiting KM_TERM, the desktop retains the selected KM_TERM 
  18. palette.
  19. --> Now fixed in v1.3
  20.  
  21. ----------------------------------------------------------------
  22.  
  23. 3. It has been said that KM_Term can refuse to run after DTerm has 
  24. been used and reports a bad channel error; apparently if you double 
  25. click on KM_Term several times it will eventually run.
  26. --> I suspect that DTerm sets up some system variables that 
  27. conflict with the ST's standard VT52 emulation mode. I've noticed 
  28. the same error message if I freely mix Power BASIC's LOCATE & PRINT 
  29. commands with the GEMDOS calls cconws and cconout. As it's an 
  30. internal ST system problem I doubt if it can be fixed, but similar 
  31. problems don't appear to occur with other programs as I've 
  32. regularly run other programs from within KM_Term and vice-versa, 
  33. including some that are much more sophisticated than DTerm (e.g. 
  34. FzDz)
  35.  
  36. In this particular instance, however, it's difficult to attribute 
  37. blame to any individual program since both were being run from the 
  38. ETERNAL RAM disk (which could itself be a cause of a clash I 
  39. suppose)
  40.  
  41. ----------------------------------------------------------------
  42.  
  43. 4. A bug crept into versions 0.7 onwards that prevented the VT52 
  44. esc-Y positioning from working correctly - thanks to Mark Matts for 
  45. helping to discover this one.
  46. --> Fixed in version 1.63 onwards (It appears that the lack of setup 
  47. required for KM_Term may have masked this one; KM_Term may have been 
  48. responding to ANSI codes correctly when I assumed it was handling 
  49. VT52!)
  50. Actually this one really made me feel small; it seems that about 20 
  51. characters from a bit of good code somehow went missing (spot the 
  52. backspace key repeat!!) but unfortunately the code still made sense 
  53. to the compiler - ah well..
  54.  
  55. ----------------------------------------------------------------
  56.  
  57. 5. The standard rate Mercury call charging was reported as being way 
  58. out.
  59. -->When I checked this I couldn't duplicate it, but on closer 
  60. inspection I realised that whereas my call cost rates were separated 
  61. by commas, the standard ones built in to the default configuration 
  62. were separated by spaces; this caused KM_Term to interpret the 
  63. standard rates as [standard] x 10^[economy] - whoops.
  64. The simple way to fix this is to change the spaces in the 'T1>' to 
  65. 'T4>' lines to commas with a text editor. The defaults are fixed in 
  66. v1.7.
  67.  
  68. ----------------------------------------------------------------
  69.  
  70. 6. It has been reported that KM_Term doesn't allow the download and 
  71. upload paths to be on different drives to the main program. This 
  72. turned out to be a GEMDOS 'dsetpath' feature (bug!) that is fixed 
  73. with some hard disk driver software (This is why it was overlooked 
  74. unfortunately). I have overcome this problem in v1.8.
  75.  
  76. ----------------------------------------------------------------
  77.  
  78.  
  79.  
  80. No other reported bugs at 2 November 1992
  81. =========================================
  82.  
  83.