🚀 go-pugleaf

In article <Y94MX83@drivax.UUCP> frotz%drivax@uunet.uu.net writes:
>woodside@ttidcb.tti.com (George Woodside) writes:
>
>] I've had some success at using Codeview with MSC 6.0 to debug GEM
>] applications, but I still have a few problems.
>
>] The following batch file puts the target software on the VGA, and the
>] Codeview display on the monochrome display:
>
>] @echo off
>] ...
>] gemvdi cv /M /2 /X %cwd%%1.app
>] ...
>
>] The only problem with this script is that the mouse is limited to
>] the top half of the screen. 
>
>Where is the mouse limited?  GEM or in Codeview?  You may have to give up
>use of the mouse in Codeview and let GEM have it.

The mouse limitation occurs in the GEM program only while the GEM
program is running under Codeview (aka debugging). When running in GEM
alone, things are correct. The /M parameter in the codeview (cv) line
in the batch file tells Codeview to leave the mouse alone, the
application being debugged is using it. When debugging non-GEM
software, and not using the mouse in the software, Codeview uses it
properly, and with no problems. The fact that the mouse works fine
in any situation other than a GEM program being debugged under Codeview
indicates (to me) that there is either something else I have to do
to normalize things, or that there is some incompatibility between
GEM and Codeview.

MSC 6.0 comes with a replacement mouse driver that must be used when
Codeview is used. It will not work with any older mouse driver. And, I
was never able to get Codeview, GEM, and a target program all up and
running in versions of MSC prior to 6.0, since none of them would use
extended or expanded memory. Now Codeview will use the additional
memory, both for itself, and for the source files of the program
being debugged. That leaves nearly all normal memory free for GEM, and
the target program. If I can get the mouse problem solved, things 
would be quite nice for debugging. Being unable to get the mouse below
the middle of the screen makes it nearly impossible to deal with the vast
majority of dialogs, since all the exit buttons in nearly every dialog
box are at the bottom, which puts them out of mouse range.
-- 
* George R. Woodside - Citicorp/TTI - Santa Monica, CA *
* Path:       woodside@ttidca                          *
*   or:       ..!{philabs|csun|psivax}!ttidca!woodside *