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