[RESOLVED] compileing files that are outside the project

I need to know how to include other files (eg. *.dll) in the compiling prossess and then extract them when the exe file is executed to specific directory so they can be used later



all help is appresiated :)

Welcome to the forums :wave:

May i ask what is the purpose of the task? Perhaps it can be resolved some other way - perhaps, by creating a setup package with already existing deployment systems?

i already knew of that option b/c my program is being distributed in a setup app with other stuff, but i want to do it this way for my own reasons and if i can't then i can do what u sujested

ps - i saw it done before

You can stick the files in a Resource file (as a custom resource), extracting them at run time with LoadResData and then writing them to disk with Put

Quote:

---

Originally Posted by Milk

You can stick the files in a Resource file (as a custom resource), extracting them at run time with LoadResData and then writing them to disk with Put

---

Yup. :)

There's a resource file tutorial on here that you might want to search for. But to summarize:

In VB:

1. Cilck Add-Ins menu -> Add-In Manager
2. Select "VB 6 Resource Editor"
3. Check the boxes "loaded/unloaded" and "load on startup"
4. After that you should see a little green icon appear in the top toolbar
5. Click that and the resoruce edit window should appear
6. Hold your mouse over the buttons to find 'Add custom resource' (it's a little gray box thing)

7. Select your DLL file to add it in there. It should show up in a "CUSTOM" folder with the ID 101. You can change this, but if you were to keep it like this the code would be something like:

vb Code:

Private Sub ExtractDLL()
    Dim strPath As String, intFF As Integer
    Dim bytData() As Byte
    
    'Path to save DLL to.
    strPath = App.Path & "\myDLL.dll"
    intFF = FreeFile
    
    'Get DLL binary data from resource file.
    bytData() = LoadResData(101, "CUSTOM")
    
    'Save data.
    Open strPath For Binary Access Write As #intFF
        Put #intFF, , bytData()
    Close #intFF
    
    Erase bytData()
End Sub

ok sweet :thumb: i'll try that tommorrow, see if it works :)

It's a bad move to install a program that way for a number of reasons:

1 - If the dll/ocx is older than the one already on the system you will register it and other programs may crash.

2 - If you register your dll then remove it there will be problems with other programs using the dll of the same name.

This is especially true if you extract the files each time you run. You are looking for loads of trouble. Well maybe not you but your intended victim.:bigyello:

I've not actually tested this, but I'm not sure you have register the file at all (won't work in the IDE, only when compiled), not only that, you don't have to use the System 32 directory, you can drop it in the Application root folder and it should still work. If this is true are the risks really so high?

If it is a .Dll it needs to be registered in order to be used.

:blush: I've just tested this and your right... well for most *.dll's anyway. Qcards32.dll seems to work without registering it... but my knowledge is not enough to know if it somehow auto-registers when referenced

Well, I don't know anything about Qcards32.dll either, but, what randem said in Post #7 is right on the money.

@someguy4: You are setting yourself, and, in all likelyhood, the people that will use this app, up for potential issues.

Quote:

---

Originally Posted by someguy4

ps - i saw it done before

---

Are you sure that what you think you saw is what you saw?

I could make an installation package named MyApp.exe that, when you run it, does a normal installation of my program, named MyApp.exe, along with all its dll and ocx files. It would be a normal deployment program, but it would look as if it was just my application installing its own files. That might be what you saw.

Agreed that an installer is the best way to go for sure. I would only use a custom resource if you have other types of files (WAV files, etc.).

You can extract the DLL to the app folder but only if you're making API calls to that DLL, ie:

vb Code:

Public Declare Sub MyFunction lib "myDll.dll" (blah, blah, blah)

But I think OCX files you can just put in the app folder, but maybe I'm wrong.

tks Milk and DigiRev:D, i think the stuff u gave me(in post #4 and 5) is going to work but stay posted just in case it doesn't(may tak a while)


k the dll file is not a sys file it's one that no one would have so it won't cause any problems in that regard

Windows dll's do not need to be registered, but you are thinking along the lines of Windows 3.1 and DOS about not needing to register dll/ocx's.

it works

tks everybody :D