How to get disk size in VB6
Bu
Can somebody tell me what VB6 code i need to get the size of a disk?
Thanks in advance
Bu
Mike Williams
news:a63tf5tiqupm6vo5a...@4ax.com...
> Hello, Can somebody tell me what VB6 code
> i need to get the size of a disk?
Have a look at the following (make sure you read some of the important
notes):
http://msdn.microsoft.com/en-us/library/aa364937(VS.85).aspx
Here's how you can use it in VB6:
Mike
Option Explicit
Private Declare Function GetDiskFreeSpaceEx Lib "kernel32" _
Alias "GetDiskFreeSpaceExA" (ByVal lpRootPathName As String, _
lpFreeBytesAvailableToCaller As Currency, _
lpTotalNumberOfBytes As Currency, _
lpTotalNumberOfFreeBytes As Currency) As Long
Private Sub Command1_Click()
Me.AutoRedraw = True
Dim totalBytes As Currency
Dim BytesFreeToCaller As Currency, BytesFree As Currency
GetDiskFreeSpaceEx "c:\", BytesFreeToCaller, totalBytes, BytesFree
totalBytes = totalBytes * 10000&
BytesFreeToCaller = BytesFreeToCaller * 10000&
BytesFree = BytesFree * 10000&
Print "Bytes free to caller: "; BytesFreeToCaller
End Sub
Larry Serflaten
"Bu" <s...@si.si> wrote
> Hello,
> Can somebody tell me what VB6 code i need to get the size of a disk?
If its for your own use, you could use WMI:
Private Sub Command1_Click()
Set WMI = GetObject("winmgmts:")
For Each DSK In WMI.ExecQuery("Select DeviceID, Size, FreeSpace from Win32_LogicalDisk", , 48)
Debug.Print DSK.DeviceID, DSK.Size, DSK.FreeSpace
Next
End Sub
LFS
Bu
Larry and Mike thanks for the fast response.
I go for Larry's solution. Just wondering why you can ue it only in
your own code.
Bu
mayayana
management introduced with either Win2000 or
WinME. (I'm not sure which.) It's not Windows
API. Earlier systems will not have it unless it's
been specifically installed.
On NT systems WMI runs as a service. If the
WMI Process Launcher service has been shut off
then WMI is not available. (I'm not sure whether
there might be another service dependency.)
Since WMI is mainly used by system administrators
via scripting, others could have it shut down for
security or performance reasons.
So while there's a good chance that you'll be able
to use WMI on any system where you ship your
software, it's not certain, and taking that risk is
unnecessary when you can easily use the Windows
API instead.
On top of that, WMI is slow, bloated, and really
provides little of interest other than system info.
It has Windows Installer functions that are just an
inferior wrapper around existing WI APIs. It has
Registry functions that are poorly designed and
superfluous if you have the Registry API. Etc.
Bu
wrote:
Mayayana thanks for the clarification
Bu
Tony Toews [MVP]
> WMI is a tool for system info.
I've seen WMI before and never quite trusted it. Thanks for your
extensive thoughts.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
mayayana
> > WMI is a tool for system info.
>
> I've seen WMI before and never quite trusted it. Thanks for your
> extensive thoughts.
>
I think it was mainly produced for sys. admins.
I looked into it because I do a lot of scripting.
The SQL-style design provides a lot of ways to
gather information, but it's also a pain in the
neck to deal with the syntax. And when I really
looked into it I just didn't find much of value.
I get the impression that a lot of sys. admins
like it because it's suited for using across a network
on a large number of machines. I've never worked
on a network, so I can't speak to that.
I use it now sometimes for VBScript Registry
access. But I don't understand why MS marketed
it to programmers. I remember a big article about
it in VBPJ when WMI first came out, as though
it were some sort of new Swiss Army knife for VB
programmers. That just didn't make sense to me.
Anyone who has VB, unless they're trying to knock
off a system info. program without writing drivers,
has no use for WMI that I can see.
Larry Serflaten
"mayayana" <mayaX...@rcXXn.com> wrote
> Anyone who has VB, unless they're trying to knock
> off a system info. program without writing drivers,
> has no use for WMI that I can see.
Except that it gets just about any system info with
a minimal amount of code. Great for one-off quick
access, but for reasons you pointed out, not a good
choice for public use.
LFS
Bu
Allthoug my program will be used in a small group i changed my program
based on Mike's suggestion.
Everybody thanks on your comments
Bu
Karl E. Peterson
>>>> I go for Larry's solution. Just wondering why you can ue it only in
>>>> your own code.
>>>> Bu
>>>>
>>>
> Allthoug my program will be used in a small group i changed my program
> based on Mike's suggestion.
> Everybody thanks on your comments
> Bu
ALWAYS(!) use the code that you have the most control over.
NEVER(!) introduce unnecessary dependencies.
--
.NET: It's About Trust!
http://vfred.mvps.org
Eduardo
> On top of that, WMI is slow, bloated, and really
> provides little of interest other than system info.
> It has Windows Installer functions that are just an
> inferior wrapper around existing WI APIs. It has
> Registry functions that are poorly designed and
> superfluous if you have the Registry API. Etc.
I agree. But in a program I had to use it because I didn't find how to
do something with API.
I needed to find if an exe is running in other users sessions (other
than the CU). And I wanted the username of who's running the process.
The code that I had to use is (main part):
Dim iProcess As Object
Dim iProcesses As Object
Dim iUser
Dim iDomain
Set iProcesses = GetObject("winmgmts:") _
.ExecQuery("SELECT ExecutablePath, " & _
"ProcessId from win32_process")
For Each iProcess In iProcesses
iProcess.GetOwner iUser, iDomain
Debug.Print iUser
Debug.Print iDomian
Debug.Print iProcess.ExecutablePath
Debug.Print iProcess.ProcessId
Next iProcess