I've got a WD MyBook too, I forgot to mention. It is drive F in the screenshot I provided, and you'll see that one behaves just fine. (Which hopefully helps in ruling out that it isn't some weird fluke specific to my computer.)

SUBSTitute Drives, do not have a Volume Path Name ... But everything else does. Yahoo!

Another handy side effect, is that in moving the check to a higher level in the code it allows SUBST'ed drives to be handled in a more acurate & efficient manner. So if someone decides to SUBST a target on a floppy, CD, network drive, or anything else. It can be quickly identified and accordingly skipped.

Sorry man, wasn't ignoring you...Just got caught up in the goings on. I'll have to dig around a bit and see if I can figure out how to do that. But if it's reasonably lightweight, a dash of color might be good.

Something I'd like to see (although it might need a reworking of your current logic stuffs...) is quicker start times. Or to be more precise, faster discovery. Maybe it is just odd on my computer and nobody elses, but starting the application takes 5 seconds before the window appears. Refreshing the view locks the application up for 5 seconds. I suspect the reason is two-fold: I have a lot of devices, and you test them all one by one. My guess is that if you did each drives discovery in a seperate thread, it would take less than a second. (Of course, once you get 26 drives in your machine, it might seem a bit taxing in the threads department for a second, but given that it is pretty much all I/O blocking there ought to be no problems with a mere 26 threads.)

The reason why I'd like this is because I think this app really has a lot of potential. I have a habit of running out of diskspace on some drive or another, and the explorer Computer window is annoying with all of its disks that don't matter to me in that situation. Additionally, assuming you don't have plans already, I'd suggest doubleclick opening the drive in question and the rightclick on an item translating to a rightclick in Explorer. (The right-click stuff I can help you with; I've got experience with those APIs from my Cautomaton entry last year.) Oh, and how about a volume names column?

Something I'd like to see (although it might need a reworking of your current logic stuffs...) is quicker start times. Or to be more precise, faster discovery. Maybe it is just odd on my computer and nobody elses, but starting the application takes 5 seconds before the window appears. Refreshing the view locks the application up for 5 seconds. I suspect the reason is two-fold: I have a lot of devices, and you test them all one by one. My guess is that if you did each drives discovery in a separate thread, it would take less than a second. (Of course, once you get 26 drives in your machine, it might seem a bit taxing in the threads department for a second, but given that it is pretty much all I/O blocking there ought to be no problems with a mere 26 threads.)

5 seconds? Wow! (that sucks) But I think I might know why (and it's something I'm already working). Initially I just listed all the drives as a starting point because it makes it easier to find out if any of them have any bad habits. Like the Floppy drives (of which you have 2), that have several ... Which are unavoidable.

The floppy on my machine at the office grunts every 3 seconds (when it's empty), for about a second, which effectively makes the refresh cycle 4 seconds. Even when it isn't empty there seems to be a bit of a lag while it's being addressed before the rest can get their turn (most of which are quite fast). The optical drives while lightning fast compared to the floppys, really aren't part of the space we need to keep track of. That and I'm pretty sure that tagging it every X seconds would screwup a burn.

So I'm making the drives that are displayed and totaled selectable, and optical & floppy drives will be deselected by default. Also optical, floppy, and network drives will be removed from the local machine drive space totals by default. Which should make the load times much faster without adversely effecting the over all functionality (i think).

Mind you I'm not adverse to the multi-thread option, I just want to try this first.

The reason why I'd like this is because I think this app really has a lot of potential. I have a habit of running out of diskspace on some drive or another, and the explorer Computer window is annoying with all of its disks that don't matter to me in that situation.

Additionally, assuming you don't have plans already, I'd suggest double-click opening the drive in question and the rightclick on an item translating to a rightclick in Explorer. (The right-click stuff I can help you with; I've got experience with those APIs from my Cautomaton entry last year.) Oh, and how about a volume names column?

Volume Names? I thought we were trying to make this faster?? (hehe - jk) I've actually been thinking about this, but was more aimed toward making it part of a more in-depth drive properties/details dialog when a drive was double clicked.

Translating the Explorer rightclicks & opening drive file views is a little outside the intended scope of the project. That is more in the loader/launcher territory. But I haven't even started on that part of the code yet so nothing is carved in stone at this pont.

Volume Names? I thought we were trying to make this faster?? (hehe - jk) I've actually been thinking about this, but was more aimed toward making it part of a more in-depth drive properties/details dialog when a drive was double clicked.

Translating the Explorer rightclicks & opening drive file views is a little outside the intended scope of the project. That is more in the loader/launcher territory. But I haven't even started on that part of the code yet so nothing is carved in stone at this pont.

Fair enough. My point is mostly that right now, it is just a list of text that I can only look at. (Which is somewhat disappointing after those 5s refresh times!) When I see drives, about half the time I'll also want to interact with them. So in my eyes, it is very much in the scope of what one might expect. Either way, if you decide and if you need help with either part I practically have the code for it lying around.

Okay, Working Settings now available. Save to Registry isn't done yet, but save to memory (use in current session) & save to GotSpace.ini are fully functional.

Volume Names? I thought we were trying to make this faster?? (hehe - jk) I've actually been thinking about this, but was more aimed toward making it part of a more in-depth drive properties/details dialog when a drive was double clicked.

Fair enough. My point is mostly that right now, it is just a list of text that I can only look at. (Which is somewhat disappointing after those 5s refresh times!) When I see drives, about half the time I'll also want to interact with them. So in my eyes, it is very much in the scope of what one might expect. Either way, if you decide and if you need help with either part I practically have the code for it lying around.

Just posted build 14 with finished registry code, more settings, hotkeys, and a status bar.

I've been fighting with the progress bars idea, but so far it's winning. I either have the old style PBs that jump around when the ListView is scrolled ... Or I have to leverage the uxtheme.dll style PBs which ties me to that and may not work if the OS is skinned. I ain't given up yet, but I've got to go on to other things for a bit in the hopes of having this thing done in time for Christmas...

Cool, thanks for the input. I'm guessing from your SS that F - I are some type of card reader, yes? Is there any lag from reading it/them (like the floppies), or does it just zip through? (I gotta ask as I've no way to test it)

I've been thinking about having the height be dynamically set at runtime based on the number on drives installed on the system. (Given your extensive list...) Do you think this would be handy? Or just confusing/annoying/silly?