SHBrowseForFolder() -- A better way?

This is a discussion on SHBrowseForFolder() -- A better way? within the Windows Programming forums, part of the Platform Specific Boards category; SHBrowseForFolder looks like it may be my only choice. Is there a better way to have the user select a ...

One line of code in place of three. Please correct me if I'm wrong, but one needs to call CoInitialize() before and CoUninitialize() after to get it to work correctly. Also, I'm kinda confused as to why there is a return value of PIDLIST_ABSOLUTE when MSDN specifies that one must pass the pointer location of at least MAX_PATH to BROWSINFO.pszDisplayName for the return folder name.

Ah, the way to explicitly say to the compiler, "Hey, I'm using these DLLs." This is my first tour in Windows programming. In Linux, when I need a runtime library, that GCC doesn't already know exists, I just -L the sucker. I didn't know how in Windows. . . which is why I said:

Originally Posted by Tonto

Originally Posted by Kennedy

Oh screw!! It uses DLLs. . . <cut>

Is that really your logic?

So, yes, it _WAS_ my logic, however, now that I know how to use the DLLs it isn't so much a pain for me anymore.

Originally Posted by Desolation

I wouldn't want to disapoint you. . .

True, however, much unlike (as far as I have seen) Linux, there has to be some explicit coding (or is there some type of linker commands to make it look at a specific DLL) to make the compilier know that I want a specific run-time library/DLL. . .which ever way you want to look at it. On my Linux boot, I installed the library and compiler. GCC on my Linux boot knows about all my libs and will dynamically link to anything it needs based upon my #include's (except, of course, if I add a library later, then it goes back to the -L again).

I had found a thread that stated the way to use a DLL was something along these lines:

Which is in C++, however, I thought that this was the way to do it. . . hence the "crap" as I had not yet found the way to go from the LoadLibrary() and the GetProcAddress() to CoInitialize() and CoUnInitialize(). And, I hoped there was a better way.

But, looks like anonytmouse's example with the #pragma comment(lib, "shell32.lib") is a better way.

EDIT: I assume that this pragma command tells the linker if you cannot find a function that is listed in this code, assume that it is from "shell32.lib" and check there before ditching out?

That command links the library shell32. However, it only works under MSVC. Otherwise, you'll need to go in your project settings and then something like 'dependencies' or 'linking options'. You don't need to do all of that. I only use this method when working with plug-ins.

Good, I'm not completely brain-fried. I noticed that in Code::Blocks, that pragma command didn't work. I've been looking (for the past hour or so) as to how to pass to gcc (or whatever linker gcc is actually calling on my machine) to use these DLLs. Would any of you be so kind as to let me in on the secret? Like I said, I've been searching for the past hour and haven't had any luck yet.

EDIT: Ugh. . . I just found this. Is that what I have to do to get the ole32 and system32 DLLs usable in my program? . . . or, again, is there a "better" way?

However, for __stdcall functions, the above method does not work. For MSVC will prefix an underscore to __stdcall functions while MinGW will not. The right way is to produce the DEF file using the pexports tool included in the mingw-utils package and filter off the first underscore by sed:

pexports testdll.dll | sed "s/^_//" > testdll.def

Then, when using dlltool to produce the import library, add `-U' to the command line:

dlltool -U -d testdll.def -l libtestdll.a

And now, you can proceed in the usual way:

gcc -o testmain testmain.c -L. -ltestdll

Hooray, we got it.

Does this mean that I have to reconstruct the lib file from the DLL file then link using the new reconstructed lib file. . . THEN. . . this would create an executable that would NOT have linked in the lib file, but would rather, using the system DLL path, search the system for the approiate DLL file and call that. . .

OR. . .

Does this mean that now I have that section of the DLL statically linked into my code? . . . and if this is true does this stomp the rules for MS developement????

Sorry folks, I'm not intentionally thick. . . it is just that this is my first venture into a GUI on Windows. . . I'm used to Textual GUIs and XWindows. . . I'm not used to the Win32 API/Win programming. . . yet.