dav@gtc.com (David L. Markowitz) (04/25/91)
The dbxtool distributed with OW 2.0 is so badly broken I gave up and now run the Sunview dbxtool in compatibility mode. Among its many problems: 1. It enforces click-to-type when I have set point-to-type. 2. It frequently hangs completely (sometimes hanging the entire desktop!) when using the arrow keys in the command window. This happens every time I try to scroll back up over a command line that is larger than the window. 3. When editing is disabled, the program display window shows no indication of where the current line is (useful for setting breakpoints et. all) after single clicking. You must select something by double or triple clicking, or dragging the mouse. Sunview showed a caret, even if editing is disabled. Is anyone really using this thing? -- David L. Markowitz Genisco Technology Corporation dav@gtc.com
schwartz@nynexst.com (S. H. Schwartz) (04/25/91)
In article <1991Apr24.183505.18899@gtc.com> dav@gtc.com (David L. Markowitz) writes: > >The dbxtool distributed with OW 2.0 is so badly broken I gave up and >now run the Sunview dbxtool in compatibility mode. > >1. It enforces click-to-type when I have set point-to-type. My dbxtool uses click-to-type. Note that the default window is the source code window, so you have to click on the command window to change where input goes. Having done that, input focus stays there and follows the mouse. -- S. H. Schwartz schwartz@nynexst.com Expert Systems Laboratory 914-683-2960 NYNEX Science and Technology Center White Plains NY 10604
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/26/91)
In article <1991Apr25.143849.20688@nynexst.com> schwartz@nynexst.com (S. H. Schwartz) writes: > My dbxtool uses click-to-type. Note that the default window is the > source code window, so you have to click on the command window to > change where input goes. Having done that, input focus stays there and > follows the mouse. What he is talking about is even if you set your defaults to be focus follows mouse, when you try to set a breakpoint, or select a variable in the source window - THE INPUT FOCUS GOES THERE. This window in normally read only. You can't change anything in the window unless you enable the edit mode. So if it's read only, WHY does it put the input focus into the window than can't take any input????? When you want to execute a command in the command window, you have to click in the command window first. This is very frustrating to people who have used focus-follows-mouse for years. Everytime you do something in the read-only source window, you have to click back in the command window. Grr! -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
bergquis@nms.gdc.portal.com (Brett Bergquist) (04/26/91)
I use dbxtool under OpenWindows all the time. The first problem that you mentioned about click to type is mention as a known problem in one of the documents distributed with OpenWindows. You should remember to use run your application with the -Wfsdb switch so that your X application will not lock up dbxtool when stepping through some X code. When I debug there is an arrow pointing to the current line in the display window whether or not I have editting enabled. As for other problems, I have had dbxtool report an error while reading shared libraries, but I get around this by linking the the -Bstatic option. -- Brett M. Bergquist, Principal Engineer | "Remind me" ... "to write an General DataComm, Inc., | "article on the compulsive reading Middlebury, CT 06762 | of news." - Stranger in a Strange Land Email: bergquis@nms.gdc.portal.com or ...!portal!gdc!nms!bergquis
andrew@resam.dk (Leif Andrew Rump) (04/29/91)
In <1991Apr24.183505.18899@gtc.com> dav@gtc.com (David L. Markowitz) writes: >The dbxtool distributed with OW 2.0 is so badly broken I gave up and >now run the Sunview dbxtool in compatibility mode. >1. It enforces click-to-type when I have set point-to-type. This is a "bug" in the OpenLook specifications - well Sun don't/didn't think so but the customers do! >2. It frequently hangs completely (sometimes hanging the entire >desktop!) when using the arrow keys in the command window. This >happens every time I try to scroll back up over a command line that is >larger than the window. I haven`t seen that one before. Are you using -Wfsdb (-fullscreendebug) I have a weird idear that it may help you! >3. When editing is disabled, the program display window shows no >indication of where the current line is (useful for setting breakpoints >et. all) after single clicking. You must select something by double or >triple clicking, or dragging the mouse. Sunview showed a caret, even >if editing is disabled. There should be an arrow! Don't load files when setting breakpoints, instead follow the flow so dbxtool loads the file itself and then break= points is visible - stupid? YES!!! >Is anyone really using this thing? I have to! Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark If it's broke, fix it (The MS-DOS way) If it aint broke, don't touch it (The Unix way) If we can't fix it, it ain't broke (Maintainer's Motto) If you can't fix it, fuck it (The U-boat way)
dav@gtc.com (David L. Markowitz) (05/02/91)
schwartz@nynexst.com (S. H. Schwartz) writes: >My dbxtool uses click-to-type. Note that the default window is the >source code window, so you have to click on the command window to >change where input goes. Having done that, input focus stays there and >follows the mouse. input focus stays there and follows the mouse? It can't do both! What do you mean? And why is the default the source code window, when (again, by default) editing is disabled and you can't type into it anyway? -- David L. Markowitz Solaris Systems Division - Genisco Technology Corporation dav@gtc.com