Mail Archives: djgpp/1997/04/11/23:07:26
From: | eggert AT charger DOT newhaven DOT edu (David Eggert)
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Possible bugs in RHIDE 1.2
|
Date: | 11 Apr 1997 13:34:02 GMT
|
Organization: | Yale University, Department of Computer Science, New Haven, CT
|
Lines: | 38
|
Distribution: | world
|
Message-ID: | <5ileka$adv@babyblue.cs.yale.edu>
|
NNTP-Posting-Host: | charger.newhaven.edu
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
I just finished installing DJGPP 2.01 and RHIDE 1.2 and have encountered the
following difficulties:
1) The first is a problem I saw mentioned in an earlier news post but didn't see
an answer for. It involves the invisible mouse. If a context switch is made
to the user screen due to selecting the Run option, then when you return to
the editor screen the mouse is still visible. When you manually choose to look
at the user screen by selecting it in the Windows menu, then when you return
the mouse is still active, but the cursor is invisible.
A work-around that I found for this problem was to run rhide in Windows in a
non full-screen msdos shell. The mouse seems to stay visible under the windows
control. The moment I would switch to the full-screen msdos shell and then try
the above the mouse goes on vacation again. In glancing at the source code the
visibility of the mouse is handled differently in the above two cases. Perhaps
the manual switching could use the same code.
2) This relates to the file paths that are used in the names of the files read
and generated by rhide. If I am in the directory containing my source file
when I invoke rhide, then everything seems fine. However, if I am in a
different directory that does not contain the source file certain troubles
arise. More specifically, some of the file names in the commands passed to
gcc (or your chosen compiler) have the full path extension prepended to them,
while others assume the file to be in the current working directory. Most
notably, the Compile command includes the full path for the source file, while
the Run command does not always do so (and hence generates an error message
that the file cannot be found). Also the intermediate .o file and the final
executable are generated in the current working directory rather than that
containing the source file (I would like all of the files to end up in the
same directory). Perhaps this is considered a feature, and maybe
there is an environment variable that I am not setting that can change this.
If these are really bugs, and haven't already been handled I can try to use the
debug features of rhide to provide a more detailed analysis. Thanks for any help
you can give.
David Eggert
University of New Haven
- Raw text -