SHBrowseForFolder looks like it may be my only choice. Is there a better way to have the user select a directory (other than, of course, writing my own)?
Printable View
SHBrowseForFolder looks like it may be my only choice. Is there a better way to have the user select a directory (other than, of course, writing my own)?
How do you define "better"?
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.
Oh screw!! It uses DLLs. . . Crap crap crap crap crap!!!!
There _HAS_ to be a better way. . . anyone?
Every application that uses this particular sort of folder selection box uses SHBrowseForFolder - unless they use some wrapper around it. (Which might exist - search the web.)
Regarding Co*, you call CoInitialize at the start of your application and CoUninitialize at the very end, not before and after every call to SHBrowseForFolder.
The documentation about the whole thing IS confusing, I'll give you that.
I have an old project that uses the function, but I won't have access to it for another week.
Here is a SHBrowseForFolder sample.
Is that really your logic?Quote:
Oh screw!! It uses DLLs. . . Crap crap crap crap crap!!!!
There _HAS_ to be a better way. . . anyone?
I wouldn't want to disappoint you, but most (if not all) functions of the Win32 API are located in DLLs (kernel.dll, user32.dll ...)
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:Quote:
Originally Posted by anonytmouse
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.Quote:
Originally Posted by Tonto
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).Quote:
Originally Posted by Desolation
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.Code:int main(int argc, char* argv[])
{
hinstDll = LoadLibrary((LPCTSTR)"DGDLL.dll");
if(hinstDll==NULL)
cout<<"FAILD TO LOAD THE DLL"<<endl;
hShellHookProc = (HOOKPROC)GetProcAddress(hinstDll,"ShellProc");
if(hShellHookProc != NULL){
SetWindowsHookEx(WH_SHELL, hShellHookProc, hinstDll, 0);
}else{
cout<<"FAILD TO CONNECT TO THE DLL FUNCTION"<<endl;
}
return 0;
}
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?
Thanks for all your help, anonytmouse!!
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?
Okay, I'm apparently thick. . . but I don't know that understand:
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. . .Quote:
Originally Posted by MinGW Website
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.
Found it. . . I was just being thick. . .
Essentially, all I have to do is -lole32
I did try it everywhich way, but that one. . . -lole32.dll doesn't work ;).
Just 'FYI', you don't link to dll's (dymanic link libraries), you link to static normal libraries, object files, and import libraries (which give you access to dynamic libraries' functions).
Hmmmm. . . I did. . . and it worked. So, I guess the next question is: How am I supposed to link to DLLs?
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)
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.Quote:
Originally Posted by Tonto
The DLLs will be standard on the operating system so you don't really need to worry about it.Quote:
Originally Posted by Kennedy
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?