Order of events in a Refresh?

[dbminter]

LUK, what happens, and in what order, when a Refresh (F5) is done? I ask because I came across this situation. I had a case where I needed to create an MDS linking to multiple image parts contained across two discs, each inserted into a different drive. ImgBurn was open at the time I inserted a disc into a drive it had been using, so, I knew I'd need to Refresh to get access to the drive, or close ImgBurn and reopen. When I pressed Refresh, ImgBurn returned a dialog because the last file it had used to burn was no longer there. I had deleted it, so, that's not the problem. But, the dialog only has Retry and Cancel on it. So, it seems that this refresh for the loaded file name occurs before whatever happens that "frees" the drive because after Cancel, the only option I could use, the drive was still inaccessible. (I even tried switching to a different mode so the file field would be blank and Refreshing, but, the drive still wasn't accessible.) So, I closed and reopened ImgBurn, but, it made me wonder. I am guessing that the drive refreshes are done then after the refresh for the file field. And, if so can they/should they/shouldn't they be moved in order of operation to occur before a file existence check?

[LIGHTNING UK!]

changing modes always kills the drive handle, so if that didn't work, refreshing orders was not the problem.

 

Also the refresh procedure does not rely on the file refreshing to be successful for it to refresh the drive.

 

The file refresh does happen first though and must stay that way. It's done in the foreground by the main thread. The drive one is done in the back ground by a 2nd thread and the refresh function does not wait for that to finish.

[dbminter]

Must have been a case where the drive refused to be given up until the application exited.

[LIGHTNING UK!]

Windows only ever has a split second to react to the handle being closed before it's then reopened. To be honest, I'm amazed that refresh ever worked in the first place - especially as virtual drives react so much faster than real ones.

 

The drive is always 'given up' by the program, it's just a case of it Windows gets a chance to butt in or not. You'd probably need to refresh ImgBurn and refresh explorer at exactly the same time. Of course you could just switch to another drive, but the closing / reopening the program may be just as quick.