We use Utility ("Choosefile"…) to allow a user to display a txt file.

We have a user who receives the message "G: drive cannot be selected right now".

The strange thing is that just before he does this, our application has read OS files in that directory and created OS files in that directory. And, if he uses Windows Explorer, he can see the files in the specified directory and open them. He can also open them with the file open dialog in notepad.

Can anyone think of a reason why this message would be returned?

He is using Win 95 and Novell 4.11.

Thanks in advance

Andy Gilman

Andy,

We use Utility ("Choosefile"…) to allow a user to display a txt file. We have a user who receives the message "G: drive cannot be selected right now". The strange thing is that just before he does this, our application has read OS files in that directory and created OS files in that directory. And, if he uses Windows Explorer, he can see the files in the specified directory and open them. He can also open them with the file open dialog in notepad. Can anyone think of a reason why this message would be returned? He is using Win 95 and Novell 4.11.

Hmm … strange. I've never seen or heard about such a thing so I'm just guessing here:

1) Version of MS or Netware client software has a bug?

2) You are not OSCLOSEing your files and are using up the file handles for the app? (Perhaps try a FLUSH immediate before.)

3) Maybe very low on system resources? Sometimes errors related to low system resources are misinterpreted as other specific errors.

4) Maybe some configuration issue with that workstation, since you said it happened for only one user (does that mean for only one workstation?) related to how the drive is mapped, how the card is configured ….

The CHOOSEFILE utility is mapped to the Windows common dialog functionality, so the error message is not being produced from OpenInsight AFAIK. That makes it hard to determine the exact cause.

Cameron Purdy

info@revelation.com

Cameron,

Thanks for the guesses.

] 2) You are not OSCLOSEing your files and are using up the file ] handles for the app? (Perhaps try a FLUSH immediate before.)

I know its not this, we are OSCLOSing. All we are doing is showing him a list of files and opening the one he chooses with notepad. When the G: drive can't be selected , Choosefile shows him the current directory correctly.

] The CHOOSEFILE utility is mapped to the Windows common dialog ] functionality, so the error message is not being produced from ] OpenInsight AFAIK. That makes it hard to determine the exact ] cause.

I thought that was probably the case.

However, he says he can start notepad himself, do file/open and select the directory. Of course the file open dialog is different than the one produced by Utility(Choosefile…). This is an area I don't understand. What is the reason for the different file open dialogs under Windows, and why might one be able to select the drive and the other not?

Andy Gilman

Andy,

What is the reason for the different file open dialogs under Windows

My guess is it is related to Windows version compatibility. The structure used to call the common dialog is prefixed with a size which Windows can use to determine version.

Alternatively, it may be related to 16-bit vs. 32-bit.

Cameron Purdy

info@revelation.com

Hi Andy,

I had the same message the other day, using the utilty("CHOOSEFILE",…) function. I could not use drive D at all, but could select C,E,F,G,H,I,J drives. So, I checked out the replies to your post, looked at resources etc, nope, same message. This morning I come in, tried the function and it works. So, I could only guess and say it was file handles (which I think Cam mentioned). Here is what I did the other day

InputFileName=d:\bwf\short2.wav"

gosub file_setup ;* see code below

…. and then with testing, etc, I just closed the form/window in OI, and there never was an "OSClose inputFileHandle" done

I know in Clipper if a successful close is done, the same handle number is used at DOS level, and there is a method to check on the number of handles 'left', and do some housekeeping.

However, this appeared to be more than just a (single) file handle on a single file, because the API open file dialog box utility("CHOOSEFILE",..) just simply refused to let me select drive D at all. The message "Drive d: cannot be selected right now. Try again later" continued. It couldn't have been overall system resources because it didn't work when I had 63% and it is working now with 41% resources available. I also have nearly 3 times as many tasks open now.

The reboot did it, I'm assuming the problem was file handles. Now what do people suggest as a good practice in coding ? Should we try an OsClose on DOS files that are hardcoded like var Inputfilename ?

I'm still a bit confused though, and not totally convinced it is file handles, because file handles is system wide, and this error was drive specific. Also, I have FILES=255 in the CONFIG.SYS ?

Arrghh, back to the drawing board.

Pedro

* File_Setup: readOffset=0 writeOffset=0 recount=0 wrcount=0 OSOpen inputFileName to inputFileHandle Else Call Msg("","Problems with inputfile") Return NULL$ End return

If you OsOpen you should always osclose otherwise you will run out of file handles…

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...