--- In [email protected], Rob Kennedy <[EMAIL PROTECTED]> wrote: > > Of course, any function that receives a pointer to a buffer should > also receive a number indicating the size of that buffer.
Generally, I'd agree. But in the case of Windows.GetModuleFileName there is no buffer length parameter, so the wrapper function also has to trust that the programmer has allocated a big enough buffer. > I think if the program wanted to know the path of the DLL, it > should just call GetModuleFileName itself. No need for the DLL to > export a function for that. True. (That thought occurred to me too.) But unfortunately the OP was not clear on what his intention for this function is, where the function will be called from, or how the DLL will be loaded... However, a while ago, I once had the need myself to get my DLL to "tell me" where it lives (strange as that may sound). I was testing calling custom DLLs from Microsoft Access. In Microsoft Access you can't load DLLs dynamically, so Access just follows a precedence of where is looks for the dll when you only specify a DLL using its name (without providing its path). Testing the "callability" (or lack of, as it turned out) of DLLs placed in the $AppPath (where the calling MDB file lives) was fascinating to me (at the time). But I won't bore you with the result of my discoveries. > If the OS loaded the DLL automatically, then the EXE > can find out the module handle by calling GetModuleHandle. Hmm. Didn't think of that. So, most likely the function will be called from inside the DLL itself (for whatever reason) in which case Workshop Alex's original function will do. Ian.
