Filesystem object or something like that in C++

Hi:
I've seen a very convenient object used in VB called Filesystem or something like that. You could do things like

Filesystem.Folders.Count

to get a count of the directories and files. Very easy.
Now, I'd like to know if theres something similar in C++, so that I could count the files inside a directory without all the trouble of doing a search and adding one by one. Or if theres a way to do it faster, at a lower level, if theres a set of API functions, or whatever.

Thanks

Comments

  • Since C++ can [b]always[/b] do more things than VB, ... sure you can!

    You can simply call CoCreateInstance to get a pointer to a Scripting.FileSystemObject object (its CLSID is [b]{0D43FE01-F093-11CF-8940-00A0C9054228}[/b] ), call the appropriate methods you need, then Release() the pointer.
    Nothing difficult at all!
    _____________________________
    [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    http://www16.brinkster.com/rafonline[/size]

  • Well, thanks for the info. I really appreciate it.
    I suspected there had to be a way to do it.

    Now a couple of questions and I won't bother anymore with this subject, do you know how the fs object works? I mean, is it just a wrapper for the file api functions or does it do something else?
    And how did you get the CLSID? I searched msdn DVD and only got an article (and only one) on the fs objects props and methods, nothing else.
    Thanks again.

    Aritosteles
  • : Well, thanks for the info. I really appreciate it.
    : I suspected there had to be a way to do it.
    :
    : Now a couple of questions and I won't bother anymore with this subject, do you know how the fs object works? I mean, is it just a wrapper for the file api functions or does it do something else?
    : And how did you get the CLSID? I searched msdn DVD and only got an article (and only one) on the fs objects props and methods, nothing else.
    : Thanks again.
    :
    : Aritosteles
    :

    You can check in the Registry for GUIDs and CLSIDs.
    As for its workings, well, look at the OLE Viewer and you'll get its Typelib (You can find its CLSID there, too, by the way), with fully listed properties and member functions.
  • : You can check in the Registry for GUIDs and CLSIDs.
    In fact, that's what I've done. No slower than 20 secs.

    As for the implementation of the FSObject, it's a wrapper for the Win32 API but with some added code to simplify a programmer's life; the property you mention is an example as it saves you from coding a loop.
    _____________________________
    [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    http://www16.brinkster.com/rafonline[/size]

  • : : You can check in the Registry for GUIDs and CLSIDs.
    : In fact, that's what I've done. No slower than 20 secs.
    :
    : As for the implementation of the FSObject, it's a wrapper for the Win32 API but with some added code to simplify a programmer's life; the property you mention is an example as it saves you from coding a loop.
    : _____________________________
    : [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    : http://www16.brinkster.com/rafonline[/size]
    :

    Well, everything is built on top of Win32 API, so it's no surprise.



  • [b]Out of topic[/b]

    : Well, everything is built on top of Win32 API, so it's no surprise.
    In the Win9x world, your statement is always true.
    But the NT native API (WinNT/Win2000/WinXP) has few to do with it, and some NT-only DLLs/EXEs do actually use it mixed with Win32 API calls.
    Also, in the NT world, every Win32 call is translated into some NT native calls.
    _____________________________
    [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    http://www16.brinkster.com/rafonline[/size]

  • :
    :
    : [b]Out of topic[/b]
    :
    : : Well, everything is built on top of Win32 API, so it's no surprise.
    : In the Win9x world, your statement is always true.
    : But the NT native API (WinNT/Win2000/WinXP) has few to do with it, and some NT-only DLLs/EXEs do actually use it mixed with Win32 API calls.
    : Also, in the NT world, every Win32 call is translated into some NT native calls.
    : _____________________________
    : [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    : http://www16.brinkster.com/rafonline[/size]
    :

    Yes, I agree. But, by "Win32 APIs" I meant... well, have you ever read Richter's "Advanced Windows"?
    Anyway, I consider the "Win32 API" to be the WinNT APIs, which Win9X APIs are a subset of.

    XP is really built on NT? I really don't believe so... it may be Unicode, or whatever, but don't tell me it's a NT-based system..
  • : Yes, I agree. But, by "Win32 APIs" I meant... well, have you ever read Richter's "Advanced Windows"?

    No I haven't... nor I have any idea about who he is...


    : Anyway, I consider the "Win32 API" to be the WinNT APIs, which Win9X APIs are a subset of.

    That's not it! NT native API is [b]not[/b] the Win32 API, it is... the NT native API! On NT-based systems, the Win32 API are actually translated into some other NT native API... think of it (NT native) as a lower layer... in fact, all NT device drivers [b]must[/b] use it.


    : XP is really built on NT? I really don't believe so... it may be Unicode, or whatever, but don't tell me it's a NT-based system..

    Unicode has nothing to do with API. It's a character format fully incompatible with ANSI, and NT kernels offer native support for it.
    Since Windows XP shares the same driver model (the lower programming layer) as Windows 2000, then it's entirely built on an NT kernel. You can read it on M$'s site, too.
    XP also has several Win32 compatibility modes (other than the ordinary one), which allow it to be bug-by-bug compatible with earlier versions of Windows (namely, 95 & 98).
    _____________________________
    [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    http://www20.brinkster.com/coldshine[/size]

  • : : Yes, I agree. But, by "Win32 APIs" I meant... well, have you ever read Richter's "Advanced Windows"?
    :
    : No I haven't... nor I have any idea about who he is...


    [b]*LOL* He wrote "Advanced Windows" for MS Press, a very good book about very advanced topics - IE: processes, threads, kernel structure, and memory management.[/b]
    :
    :
    : : Anyway, I consider the "Win32 API" to be the WinNT APIs, which Win9X APIs are a subset of.
    :
    : That's not it! NT native API is [b]not[/b] the Win32 API, it is... the NT native API! On NT-based systems, the Win32 API are actually translated into some other NT native API... think of it (NT native) as a lower layer... in fact, all NT device drivers [b]must[/b] use it.
    :

    [b]Okay, it's just a matter of words, then... but I didn't knew about these things about drivers, though they were easy to guess. [/b]

    : : XP is really built on NT? I really don't believe so... it may be Unicode, or whatever, but don't tell me it's a NT-based system..
    :
    : Unicode has nothing to do with API. It's a character format fully incompatible with ANSI, and NT kernels offer native support for it.
    : Since Windows XP shares the same driver model (the lower programming layer) as Windows 2000, then it's entirely built on an NT kernel. You can read it on M$'s site, too.
    : XP also has several Win32 compatibility modes (other than the ordinary one), which allow it to be bug-by-bug compatible with earlier versions of Windows (namely, 95 & 98).
    : _____________________________
    : [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    : http://www20.brinkster.com/coldshine[/size]
    :
    [b]I know what Unicode is.
    Besides, for Unicode characters in the ANSI set, conversion is *very* easy: drop every even byte, and you're done. Or, cast Unicode strings into a "short*", then assign the whole "short" value to a "char" type. It will do.

    I didn't knew about Xp's compatibility modes, though. [/b]
  • : *LOL* He wrote "Advanced Windows" for MS Press, a very good book about very advanced topics - IE: processes, threads, kernel structure, and memory management.

    Try this: http://www.mvps.org and you'll find a new way to save some money...

    : Besides, for Unicode characters in the ANSI set, conversion is *very* easy: drop every even byte, and you're done. Or, cast Unicode strings into a "short*", then assign the whole "short" value to a "char" type. It will do.

    Then you probably don't understand what the MultiByteToWideChar and WideCharToMultiByte functions are for... what if the first char in my Unicode string is 0x8C00 ? Will your program truncate it? Yes, it will indeed!!!
    _____________________________
    [size=1][b][grey]Cold[/grey][blue]Shine[/blue][/b]
    http://www20.brinkster.com/coldshine[/size]

  • : *LOL* He wrote "Advanced Windows" for MS Press, a very good book about very advanced topics - IE: processes, threads, kernel structure, and memory management.

    Try this: http://www.mvps.org and you'll find a new way to save some money...

    *LOL* I didn't knew.

    : Besides, for Unicode characters in the ANSI set, conversion is *very* easy: drop every even byte, and you're done. Or, cast Unicode strings into a "short*", then assign the whole "short" value to a "char" type. It will do.

    Then you probably don't understand what the MultiByteToWideChar and WideCharToMultiByte functions are for... what if the first char in my Unicode string is 0x8C00 ? Will your program truncate it? Yes, it will indeed!!!

    Yes, I know. That's why I said "for Unicode characters in the ANSI set".
    Of course, it will truncate two-byte chars.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories