Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Getdir() fails to return empty USB-disk 3

Status
Not open for further replies.

Yrmann

Programmer
Nov 14, 2002
5
0
0
NO
My users often uses USB-disk to take a backup, and my backup function uses getdir() to select the drive/disk to store the zipped backupfile.
If the usb-disk is not empty everything goes well. With a new empty usb-disk getdir() returns the deafult folder. We use the "Drive" dialogue in the bottom to selct the USB-disk. I have no chance to detect that another disk is chosen when getdir() returns the deafult one. I have tried on many different computers, same result.
Have anyone experience with this?

Kind regards Rune
 
Hello Rune and welcome to the forum.

Can you explain what you mean by an "empty" USB disk. Do you mean one that is fresh from factory - that has never had any data on it? Or one on which all the data has been deleted?

Either way, I am not seeing the behaviour you describe. In both cases, [tt]GETDIR("F:")[/tt] (where F is the USB drive letter) shows the usual Select Directory dialouge, with the F drive visible both in the main part of the dialogue and in the drow-down list of drives at the bottom. (Of course, this assumes that the disk has a file system. In both my tests, this was FAT-16.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
I use getdir(), not getdir("F:"). So the user can freely select drive and folder. I have tried with fresh empty and used USB's where I have deleted all files (also hidden).
I get the same result.

set defa to c:\edag
Mfolder=getdir()
* I select F: in the drive-dialogue

* If the F: is empty

? mfolder && gives me default folder
c:\edag

Rune

 
Hi Rune,

I can reproduce the behavior, is that an alternative for you: GETDIR("","","")

Thomas
 
Thank you for your answers! It will be annoying for the users,to begin with, but it is crtical to get the backup where it belongs!

Rune
 
Gerrit,

just add the missing closing bracket ) and you'll get to the GETDIR() topic of the VFP help online hosted at MS.
You could also simply lookup GETDIR in your local VFP help.

The link just allows you to see the meaning of the nFlag value 64 (bit 5) and further flags.

Chriss
 
Hi Marco and Chris,

I know about Getdir() although I rarely use it. I was commenting just because the link didn’t work, what may be frustrating for other visitors now or in the future.

Regards, Gerrit
 
Gerrit,

and we were telling you the link is to the help topic about getdir, so it's clear the link fails, but also where it would go, if it would work.


Chriss
 
Gerrit,

and here is the working link, with the closing bracket:
[URL unfurl="true"]https://learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/dsx659xk(v=vs.71)[/url]

If you post it directly without embedding it into a [ignore][link url]description[/url][/ignore] tag (forum TGML) of the forum, the forum removes the closing bracket and breaks the link. So Marco didn't even wrote a wrong link, the forum breaks it.

Chriss
 
Yrmann said:
It will be annoying for the users,to begin with

Did you already change it and got feedback?

I had to empty a thumbdrive to check this, the actual problem is, that the normal VFP GETDIR() dialog sticks to the drive it currently shows, when there are no folders or files in the other drive at all. Also: Even if you know an empty drive and SET DEFA to it, the GETDIR dialog will switch back to C:\ or the first drive with files/folders on it. It really avoids empty drives, what a bug.

You could use this code, which would detect USB drives and add a dummy getdir.txt file, if no single file/folder is found on such a drive. When I run this with my empty USB drive attached it generates getdir.txt with 0 bytes. That should even be possible on a full drive, as a 0 byte file only needs a place in the TOC (table of contents) of the file system that reserves place anyway. Well, and for the purpose of a backup you'll want to assure there's enough free disk space anyway. If any file or folder is found on a drive they are untouched, this code does not write "getdir.txt" to any drive letter with drivetype 2, only those making problems with GETDIR() by being ewmpty.

Code:
   Local lnDrive, lcDrive
   For lnDrive= 3 To 26 && avoid 'A:\ and 'B:\'
      lcDrive = Chr(64+lnDrive)+':\'
      If DriveType(m.lcDrive)=2 && floppy disk , USB drive-
         If Empty(Sys(2000,m.lcDrive+'*.*'))
            StrToFile('',m.lcDrive+'getdir.txt')
         Endif
      EndIf
   EndFor

Your mileage might vary slightly. Because...

1. In my test DriveType() for my USB thumbdrive was 2, which by documentation means floppy disk. Watch out, if you really have a floppy disk drive just like other removable drive types, including CD/DVD/BD. Checking for files on them with SYS(2000) while no disk/sd card, CD/DVD/BD is inserted could lead to errors or long timeouts, which are even worse. Therefore not any drivetype>1 is good to go, some USB drives might also be drivetype 4, though, not sure.

2. I start at Drive C:\ (lnDrivce=3), to avoid legacy A:\, B:\ floppy disk, drivetype 2 seems to be legit for USB drives with letters C: or above, check with your own USB drives, perhaps. You might also start at D:\ and assume C:\ will always be the OS hard drive, though there are unusual setups with some thin client computers.

As GETDIR() won't show any filenames, that trick remains unseen, especially if you care for deleting the file again, after GETDIR(), no matter what drive/directory the user picks. To be able to know that, I would build a list of the generated files after each STRTOFILE() to finally remove them, again. But erasing the files can't be done in this code, it has to be done separately after GETDIR(), of course. I spared to implement that whole aspect, if you care for it, you could also leave the empty text file.

This could also be done with a WMI query for Win32_USBControllerDevice, but this is overkill and would require diving deeper into differentiating between USB drives and other USB devices, using DriveType() keeps things easy.

Chriss
 
Last not least, this also seems to work, even with empty drives:

Code:
GetDir('','','',0,.f.)
You'll also see further nodes in the dialog appear, like Desktop, This PC, Network and more.

The documentation only discusses the effect of setting this lRootOnly parameter .T. to not allow navigation above the root/default folder. Not passing this in only lists drives, but passing in .F. obviously extends the view and you then can also pick an empty drive.

Notice: When the user navigates into the network node and picks a share, GETDIR() will return a UNC path (starting with \\ instead of a drive letter). VFP can handle and work with UNC paths, so that's not a problem, but if your code expects an absolute path with drive letter, that might fail in such now possible cases.

Chriss
 
Thank you again for lot of info and suggestions. I have now implemented this with the new dialouge as this seems more secure. Also good to get confirmed that my observation was right, not to be able to return the adress of an empty disk was a really surprise! I had a customer that had taken bacup to his new thumbdrive for months, it was empty! All the backups were on c:\<somedirectory>, luckily he did not have a crash on his PC.

So this is how the users will get it from now on:

mfolder=GETDIR("C:\","Choose where you want to store your backupfile:","Storing of your backup",64) && translated from Norwegian

The positive thing is that you get an overview of all your system resources, and if you stretch the window, it will reappear in the same size next time. So I think this will be an enhancement from the old getdir(). The users just have to get used to it (they do not like any sort of change - I am sure you have experienced that.

Rune
 
Yrmann

Yrmann said:
The users just have to get used to it (they do not like any sort of change - I am sure you have experienced that.

Yesd, that's why I made more suggestions to enable going back to the old style, if you didn't yet realize that.

The last one is also changing the dialogue a bit, but not as much as the solution with nFlags=64.

GetDir('','','',0,.f.) would be my personal favorite as compromise between old look and feel while needing a small code change and no interference with files on the drives, not even temporary. It's a smaller change of look&feel than solution you now took.

On the other side the OS dialog also could be what users are used to before they even use your software. It's not rare that users firm with Winodws find the old style VFP dialogs lacking of features they are used to.

Your users, used to your dialog would be more important than them, I guess. So dialogues not in the OS design (and there are many more standard OS for selecting images, fonts, colours... known as common dialogs) are very commmon in VFP as MS often didn't update what the VFP functions/commands call up, so that stuck to older OS version dialogues.

I bet you the Fox team would blame MS for keeping the old styles for compatibility and the Windows team would blame the Foxpro team (the team that developed VFP itself, not VFP developers developing with VFP) to not adapt the language to the upgrades of each OS version.

If you want a better overview look into MS documentation of them
You can easily compare how they look in their latest version vs VFP ones, VFP also start up these OS dialogs, but as it was implemented in earlier Windows versions.

Another hellpful resource to make the most of them from VFP are some samples, for example by Yousfi Benameur, starting with part 1 at
Chriss
 
Hello Chris, thank you for your time, yes I understood that your code would have worked, as you put a file on empty disk, while scanning for empty disks. Appreciate your work, and have learned a lot!

Rune
 
For future readers, here's another important read about modernizing such dialogs using Carlos Alloattis ctl32. A talk by Doug Hennig:

In the section "File dialogs" it points out things the VFP functions lack and what's enabled using this library.
The original site for ctl32 does not exist anymore, but it was not long ago mentioned for another topic of scrallable containers.
There is an unoffical blogspot site that rescued most of the old site from web achive, including the downloads:

And one more idea woul be using PUTFILE() instead of GETDIR() to not only determine the destination of the backup zip file, but also its name. For sure this has pros and cons, too.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top