🚀 go-pugleaf

woodside@ttidca.TTI.COM (George Woodside) writes:

] 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.

You should avoid the use of the "/M /2" switches as the GDOS is being
interpreting as the GDOS mouse specification switch.  The way that the
manual specifies the GDOS /M switch is: /M=ab; where a=port and
b=mouse type.   Since '=' in does is a transparent character (eg gets
mapped to a blank) the GDOS is reading something like: "/M=/2" which
makes no sense to the GDOS.

The GDOS will look for all recognizable GDOS switches and then pass
the entire command line to the application (everything after the
application name).  This information is what is found in the GDOS'
PSP. 

Suggestions from engineers here are:

1) Rename codeview.exe as codeview.app and invoke from the Desktop.
This implies that you [are able to] set the /M, /2 and /X switches
somehow other than from the command line.  Invoke by clicking on
the codeview.app.

2) Set the /M, /2, and /X switches somehow other than from the command
line. and invoke via "gemvdi cv %cwd%1.app".

3) Debug the GDOS... (I wouldn't...) via "cv gemvdi %cwd%1.app". 
--
Frotz
[God is real, unless declared integer]