Printable View
Hi! I'm just wondering if it's possible to make a Standard EXE refer to DLLs and OCXs that are in the same directory, so that even when you rename or move the directories, as long as the DLLs are in the same path as the EXE, it will be recognised? Is this possible?
Nope mate,
u see what happens is this... when u use a dll... it refers to the Registry to realise where this dll is located so that it can call that function.... further ofcourse if u're using the DLL as an ActiveX DLL then u'll need to use the GUID of that ActiveX component or atleast QueryInterface will :)
so there's no way to tie path to a dll....
cheers
Gaurav
Actually, I've found for OCXs you can keep them in the same dir as the EXE and not worry about registering them...unfortunately the same is not true for DLLs
1 minute i maybe wrong... but isn't an OCX registered the MOMENT its built just like a dll is???
curious!!
Cheers
Gaurav
Yes OCXs are registered when compiled but you can un-register the ocx (using REGSVR32.EXE /u [filename]).
However, VB runtime dlls are found in the current directory if put there (eg. for a setup program on a CD ROM)
IMHO all apps should install to a location replete with all of their controls and libraries. Yes you would have multiple copies of controls and such but it would be guaranteed that each app would have the correct versions. The need to register them would be removed as each application looks in its own directory for the necessaries.
It sounds archaic and will fill up HD space quicker but with the ballooning volumes this isn't really an issue. Maybe it will assist developers in the art of neat code! Remember when all we had was 64k or less?
Someone - It can be done - but only in W2K. With 2000 you can place a file called app.local in the app directory and this tell the operating system to look in the local app path for all dll's, ocx's, etc first. It's new to 2K though so not much use if you're not using that.
Thanks for the replies!
Hmm... I might opt to change those DLLs into OCX files, but first, how do I go about making it always refer to the OCX in the same path as the EXE then?
It's a bit annoying that when I rename the directory, the EXE can't be run.
I have a question pertaining to this thread (if anyone still cares since it's been awhile), what would happen in such a case:
suppose a system already has richtextbox32 registered. But my program has it's own copy (just in case it isn't registered) if I register my copy of richtextbox32, will it ignore the orignal copy?
I would like for it to use it's own richtextbox while running the program, but allow the user to use the system's native one when it is running other programs.
Is there a way to detect which OCX's a present (programmatically), cuz there's a function in my company's software that uses a few OCXs but they dont want to use a setup program.
Francis.
Well, I think Nepolean Bonaparte said it once. Might as well repeat that.
Yes, Someone, I think what you are suggesting might be possible. While distributing your application, in the P&DW, it asks you the location where different components will be installed. Edit that part sothat all the DLL and OCX files have a location same as the application EXE file.
I think DLLs need to be registered, but they need not be in the same folder C:\Windows\System or whatever. You can have them anywhere on your hdd, just register them. Location does not matter.
Thanx for the reply! And I've found out that the Packaging Wizard does allow me to set the path of the DLLs to the same path. Well, that part's done.
Another problem occured though. I tried accessing the file through a network (i.e. sharing my drive with the EXE and running it from another computer directly). Well, it can't access the DLLs NOT made by me (COMCTL32.OCX gave an error that is not registered). However, it could access the OCX /DLL files that I made myself.
Anyway around this?
The application still has to be installed on each PC the app is going to run on.
By putting the DLLs and OCX in the apppath you are merely registering thier presence to the client. eg PC1223 'knows' that the files are on server12\common\apppath *but* PC1233 doesn't. It's versions of the files are registered as being in the local space ie it's harddrive.
As I said in my earlier post if the application doesn't require the registering of componentry by version, but rather each application has a space in which its components are registered then version/licence/registration conflicts will not happen.
You will still need to 'install' the application but all you are doing is adding a registry key with the necessary pointers. As simple as double clicking a .reg file...