Howdy, Stranger!

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

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

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
«1

Comments

  • ColdShineColdShine Posts: 597Member
    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]

  • aritostelesaritosteles Posts: 10Member
    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
  • GenjuroGenjuro Posts: 913Member
    : 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.
  • ColdShineColdShine Posts: 597Member
    : 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]

  • GenjuroGenjuro Posts: 913Member
    : : 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.

  • ColdShineColdShine Posts: 597Member


    [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]

  • GenjuroGenjuro Posts: 913Member
    :
    :
    : [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..
  • ColdShineColdShine Posts: 597Member
    : 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]

  • GenjuroGenjuro Posts: 913Member
    : : 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]
  • ColdShineColdShine Posts: 597Member
    : *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]

«1
Sign In or Register to comment.