userlib path
BlitzPlus Forums/BlitzPlus Programming/userlib path
| ||
| i am in need of accessing a userlib that is not in a windows directory and is not in my application path (it is installed in a certain, dynamic location by another software product). i cannot seem to get the userlib functionality to find the userlib file. i tried setting the PATH environment variable but that did not work. i also tried using CurrentDir() and ChangeDir() to change the current directory before i called the DLL function. any ideas out there or anyone with insight into how the userlib functionality locates files? thank you. |
| ||
| Did you try .lib "c:\blah\blah\pathtodll\dll.dll"? |
| ||
| greetings Eikon :) while that may work (havent tried it), i need it to be dynamic since the user could have installed it to any directory :( i read the path to the DLL from the registry. i did try something like: .lib gcPath$+"dll.dll" and was planning on setting a global var but the compiler err'd when i tried to build the EXE. said it was expecting a string :( |
| ||
| hmmm. heres a thought, i could copy the DLL (its not an activex dll) to the app folder and then delete it when im done. boy thats ugly but it may be the only way... |
| ||
| If you want to do that you'll need to use CallDLL instead of a userlib. Something like CallDLL regpath$ + "\mydll.dll", func |
| ||
| thx Eikon. i was looking into that and i got the impression from the help that the DLL called needed to be written specifically for blitz (based on the example C function declaration). the function i need to call has 5 params ($,$,$,%,$) and returns a %. im getting decent with banks, but im not sure how i would define the IN bank for the function call. is there a direction you can point me towards more info? <edit> i found one example in the forum that builds a bank of banks (using an integer to point to a bank for each $ that needs passed) to pass to a function call. i think this is what i need to do? |
| ||
| Actually, if you've got that many params, a userlib would be ideal. Why not just declare .lib "mydll.dll" in the userlib and leave the DLL in the app folder. Then on the first run you could CopyFile it to SystemProperty("systemdir") and then DeleteFile it from the base dir afterwards, assuring it can always be located. |
| ||
| doh! was just going to go with copying it in for the run of the program but ran into 2 issues: 1) it apparently determines if userlibs exist sometime before it reaches the code. copying it in during an initialization phase still gives userlib not found. if run again with it already there it works fine. this could explain why either changing the path or setting the current directory at the time of the call didnt work for me. it had predetermined that they it was already not there. 2) there is no way i can find to flush the DLL cache. once a call is made i cannot delete the DLL file until the app is closed. grrr :| the reason i want to not move it to the systemdir is because i have no control over the install for the DLL. any subsequent installation may not update the copy of the DLL being used if i permanently move it somewhere. |
| ||
| Hmmm, a real toughie. I'm sure someone will come along with a solution. Soja... |
| ||
| This problem is a pain. It would be much better if we had control over when the program searches for the dll's, that way we could even pack them into the exe. There may be a solution but it's a bit long in the tooth: Make a batch exe that does the following: 1) Searches for the dll and places a copy of it into the applications userlib folder. 2) Use the ExecFile command to start the application that needs the dll. The application will now detect the dll and start. 3) Close the batch exe. Make another batch exe to delete the dll: 1) When the application closes, use ExecFile to call this batch exe to delete the dll from the applications userlib folder. You may need to use a delay to allow the dll to be freed. 2) Close the second batch exe. You could use one batch exe using a flag saved in a dat file. |
| ||
| greetings vip3r :) definately a pain! i have thought long and hard about this and i think the best and easiest thing for me is to write a stub DLL that will do a loadlibrary and call the functions on the one i need access to. i can keep it in the app directory and can pass a path into it for the loadlibrary. not the best, but will be adequate and easy. i thank you both for the replies :) one of the reasons i bought B+ is due to the active community that works with it :) |
   |