SHBrowseForFolder() -- A better way?

http://windowssdk.msdn.microsoft.com.../ms682589.aspx << dll main
http://windowssdk.msdn.microsoft.com.../ms686912.aspx << using dlls

http://windowssdk.msdn.microsoft.com.../ms686923.aspx << load time, import library
http://windowssdk.msdn.microsoft.com.../ms686944.aspx << run-time dynamic linking

Edit: no you did not link to a dll when you specified that link option. You probably linked to an import library called libole32.a or ole32.lib (I think that's what you meant)

Originally Posted by Tonto

Edit: no you did not link to a dll when you specified that link option. You probably linked to an import library called libole32.a or ole32.lib (I think that's what you meant)

Okay. . . this then bleeds the question: Do I _need_ to use the DLLs or can I just use the libole32. . . Keeping in mind that I'm not a Windows programmer. . . just got stuck doing this one since I'm the only programmer. . . I really don't know much about the Windows *crap* except for what I have learned over the past three months. So, which is the okay way to do it? All I'm needing is the Browse for folder function, which is what got me into this mess in the first place. The zipped file that was at the end of the thread that anony sent me to was a way to do this through OFN, however, I didn't understand much of what I saw.

Originally Posted by Kennedy

Okay. . . this then bleeds the question: Do I _need_ to use the DLLs or can I just use the libole32. . . Keeping in mind that I'm not a Windows programmer. . . just got stuck doing this one since I'm the only programmer. . . I really don't know much about the Windows *crap* except for what I have learned over the past three months. So, which is the okay way to do it? All I'm needing is the Browse for folder function, which is what got me into this mess in the first place. The zipped file that was at the end of the thread that anony sent me to was a way to do this through OFN, however, I didn't understand much of what I saw.

The DLLs will be standard on the operating system so you don't really need to worry about it.

By linking to the .a or .lib file, you do not need to do anything more than #include the proper header files to use the functions within the library. The .lib will handle the loading and unloading of the DLL and all the associated stuff like that.

The .lib file itself (like that libole32) is just a small amount of code that handles loading the DLL and calling the appropriate functions. That code is statically linked, and all it does is make it easier to access the DLL. The DLL on the end user's system does the real work.

Okay, so does this mean then that I really _AM_ using the DLL, and not statically linking to these functions? -- Again, I'm not trying to be thick, just attempting to understand. DLLs and I aren't really friends, yet.

Let me attempt to explain what I think you said, then you rip it to shreads if it needs it:
First, I know what a DLL is and does, as well as libraries (I've been writing C code since 1994, but it has been mostly on Linux with standard libraries or dynamically linked shared libraries that I don't have to do anything to get to the functions). As far as linking to a DLL, the only time that I have ever done such was in VB for an interface to an MSSQL server, which is really dumbed down (I think the code was something like uses("somedll"). But now, what you are saying (cat) is that I am using the DLLs, however, I'm not actually interfacing directly with the DLL as I'm statically linking to those interfaces. I, when I compile with -l<whatever>, hit a lib that does all the init for the DLL transparently to me.

So, is that right?