bobr@zeus.TEK.COM (Robert Reed) (10/09/87)
I have a copy of Codeview which I got with MS C 4.0 which exhibits several peculiar behaviors. This note is a query about other encounters with these problems and any possible avoidance procedures, etc: My system is a Compaq 386 running MSDOS 3.1. When I try to use Codeview to debug a program, I have to be very careful to disable the Flip option before letting the debugged program start. If I don't, the whole screen will go into reverse video, which makes it very hard to read things in Codeview. Even when I do this, when I return to Codeview at the first breakpoint, the nonaddressable margin of the display shifts to bright green. With flip disabled, output from the program gets garbled with Codeview data, sometimes creating quite a mess. I also recently acquired a Logitech bus mouse, which makes using Codeview a whole lot easier except for one problem. Either the Logitech driver or Codeview doesn't know about using the mouse in 43 line mode. If I set 43 line mode in Codeview, the cursor echo is disabled if the cursor drops below the normal (24th?) bottom line. Coordinates are making it to Codeview, because I can set breakpoints, but position a cursor that is not being echoed can be a real bitch. Has anyone encountered these difficulties? Any suggestions? -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
rhb6@bunny.UUCP (Robert H. Barkan) (10/14/87)
> I have a copy of Codeview which I got with MS C 4.0 which exhibits several > peculiar behaviors.... > My system is a Compaq 386 running MSDOS 3.1. When I try to use Codeview to > debug a program, I have to be very careful to disable the Flip option before > letting the debugged program start. If I don't, the whole screen will go > into reverse video, which makes it very hard to read things in Codeview. > Even when I do this, when I return to Codeview at the first breakpoint, the > nonaddressable margin of the display shifts to bright green. With flip > ... The Codeview/EGA bug on ibm compatibles was discussed a few months ago, but I don't remember seeing anything specific about the Compaq. Since I had the same problem, here's how I resolved it. We have 2 Compaq 386s, both with Compaq EGA boards running DOS 3.1. One of them had this color problem, and the other was fine. A little detective work revealed just two differences in the 2 EGA boards. The newer EGA board (the good one) had a higher revision number on it (don't remember the numbers), and a wire jumper across one of the chips, probably a quick fix. When I swapped boards, the problem disappeared. I then spoke to a person at Compaq who didn't acknowledge the problem, but said only "contact your vendor". After about 2 months of "*contacting* my vendor", they reluctantly sent a newer replacement EGA board. End of bright-green-and-inverted-color problem. \begin{flame} During part of the ordeal, I was asked (more than once): - was I using the right dip switch settings? - was my system configured properly? - is the software causing the problem? - was I entitled to a replacement board even though my original one was no longer under warranty? These might be valid questions for a previously unreported problem, but it seems like someone was aware of the problem, and quietly fixed it. Since the problem didn't appear on IBM machines, and the fact that Compaq makes *100%* compatibles (said the Compaq rep), was enough to finally resolve the matter. \end{flame} > I also recently acquired a Logitech bus mouse, which makes using Codeview a > whole lot easier except for one problem. Either the Logitech driver or > ... > Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK I have a Mouse Systems mouse. After the first time the output screen is shown, the mouse is not echoed. If I then blindly position the mouse in the right side of the top line, I can "dig it out" when I press the left button. I suspect this is a problem with the Mouse Systems device driver. -- Bob Barkan GTE Laboratories 40 Sylvan Rd ..!harvard!bunny!rhb6 Waltham, MA 02254 rhb6%gte-labs.csnet@relay.cs.net 617/466-2568
lotto@wjh12.HARVARD.EDU (Jerry Lotto) (10/14/87)
In article <5213@bunny.UUCP> rhb6@bunny.UUCP (Robert H. Barkan) writes: > >> I have a copy of Codeview which I got with MS C 4.0 which exhibits several >> peculiar behaviors.... >> Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK > >I have a Mouse Systems mouse. After the first time the output screen is >shown, the mouse is not echoed. If I then blindly position the mouse in the >right side of the top line, I can "dig it out" when I press the left button. >I suspect this is a problem with the Mouse Systems device driver. >Bob Barkan GTE Laboratories I too have a mouse systems mouse. When I first saw this problem, I reported it to the "mousketeers". Many months passed, but someone finally CALLED ME! They said that Microsoft had not documented one or two features of their mouse driver and thus the mouse systems emulator knew nothing of them. Apparently Codeview made use of these features (let us call them "internals"). Mouse systems did eventually come up with another driver which solved the problem. This driver is out of beta test by now and is probably available for a phone call. There is also a major upgrade to the menuing program/drawing program which they are charging for. Mouse systems was reachable at (408)988-0211 when I last looked and the driver you need is MSMOUSE.SYS or .COM. The copy I have now is version 5.03 dated Jan 1987, I am sure that later versions exist. In fact, if anyone follows up on this, would you please let me know what the current version number is? Thanks. -- Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto ARPA: lotto@harvard.harvard.edu