Re: Registering DLL Question - Part 2
- From: "vbexp" <nobody@xxxxxxx>
- Date: Tue, 25 Oct 2005 19:26:09 -0400
FYI, DllMain is the first thing that is called in any DLL. It's also called
when the DLL is unloaded with DLL_PROCESS_DETACH, so the developer is also
free to unregister the DLL at that time, which will make you scratch your
head if you closed your App without searching the registry, but I bet that
they leave the registry entries alone.
"boaz" <nospam@xxxxxxxxx> wrote in message
news:Oev09Qa2FHA.1576@xxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> After so many off topic posts, I am finally getting something.
> I tried what vbExp suggested. I checked the registry to see if there was
> any OCX there. It was not there. And then I ran my program. And
> somehow, the program added the OCX to the registry by some unknown force.
>
> Now I understand a little bit more about registering DLL.
>
>
>
>
>
>
>
>> I just copied the main EXE and the OCXs to the same folder without
>> registering anything. (just copy and paste). And it worked.
>
> The OCX may have been registered already. Try this instead: before
> installing on a new computer, search the registry for the OCX file, you
> will
> either find that it was registered before, or see my comments below about
> registering during DllMain call.
>
> Perhaps part of your confusion is that ActiveX files are called
> self-registering DLL's. This doesn't mean that they are magically
> registered, a setup program or an update utility must call
> DllRegisterServer() which is exposed by the DLL/OCX. Self-registering here
> means that the DLL/OCX will create the registry entries that it needs to
> function all by itself, i.e., self maintaining, however, an installer or
> updater must call DllRegisterServer() inside the DLL/OCX during
> installation
> time. Self-registering is actually self-maintaining, not auto register.
>
> Programs like "regsvr32.exe" and installers register a DLL by calling
> DllRegisterServer(), and unregister by calling DllUnregisterServer().
>
> Having said that, it's possible for a vendor(using C++), when the DLL is
> first loaded to check if the registry entries were present or not, and add
> them. However, many don't do that and it could be a big mistake, since
> only
> Administrators and Power Users can write to HKEY_LOCAL_MACHINE. The vendor
> may have added such a check in DllMain(), which is called when the DLL is
> first loaded. You can tell if the vendor is doing that by searching the
> registry for the OCX file, and if not found, just copy the OCX files and
> your EXE and run your EXE. While the EXE is open, search the registry
> again,
> if you find the OCX, then the vendor is registering the DLL if it was not
> registered during DllMain call, which is called by LoadLibrary API
> function.
>
> P.S.: OCX files are DLL's as far as the OS is concerned.
>
> Self Registration for Controls
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0fff07e5-10bb-4052-8eb1-021efcb66d6c.asp
>
>> Just copy and paste the EXE and their own OCXs to their own folders.
>> (and
>> add the ".local" file there)
>
> I just double checked if the .local trick works with ActiveX files created
> with VB6 when they are not registered, and it doesn't. I created a test
> DLL
> "DotLocal.dll" and an EXE that uses it "DotLocalTest.exe". I used a
> "DotLocalTest.exe.local" file, but it doesn't work.
>
>
> "boaz" <nospam@xxxxxxxxx> wrote in message
> news:uvqf%23NQ2FHA.3420@xxxxxxxxxxxxxxxxxxxxxxx
>>
>>> Ok, that makes a bit more sense. You are quite stuck then I think. You
>>> can't
>>> have 2 copies of the same third party ocx on your machine and expect
>>> different apps to use different files. OCXs shouldn't be in your
>>> programs
>>> folder.
>>>
>>
>> Now this come to my second "Original" question. (yes it is going a
>> cycle)
>>
>> So, for the sake of it, I tested my new program on a brand new Win2K
>> computer. I just copied the main EXE and the OCXs to the same folder
>> without registering anything. (just copy and paste). And it worked. And
>> according to the previoues posts, if I didn't register the OCXs, the
>> program would not work. But this was not the case. I was confused. I
>> was thinking if I did the same thing for the rest of my programs, it
>> would
>> solve my problem. (i.e.) Not to register anythng. Just copy and paste
>> the EXE and their own OCXs to their own folders. (and add the ".local"
>> file there)
>>
>>
>>
>>> If I understand the problem, you have 2 or more apps that use the same
>>> third party OCX. By updating app B and releasing it with the new third
>>> party OCXs you are breaking app A? The only solution I can see is to go
>>> ahead and release app B and allow app A to be broken. You will then need
>>> to provide an update for app A. There's no other solution I can see
>>> because you are going to have to release a new version of A because
>>> another vendor might release an app with the updated ocxs anyway which
>>> would break A.
>>>
>>
>>
>> You are correct.
>> I installed the new program and all the old programs stoped working.
>>
>>
>
>
>
> --
>> There is no answer.
>> There has not been an answer.
>> There will not be an answer.
>> That IS the answer!
>> And I am screwed.
>> Deadline was due yesterday.
>>
>> There is no point to life.
>> THAT IS THE POINT.
>> And we are screwed.
>> We will run out of oil soon.
>
>
.
- Follow-Ups:
- Re: Registering DLL Question - Part 2
- From: boaz
- Re: Registering DLL Question - Part 2
- References:
- Registering DLL Question - Part 2
- From: boaz
- Registering DLL Question - Part 2
- Prev by Date: Registering DLL Question - Part 2
- Next by Date: Re: Registering DLL Question - Part 2
- Previous by thread: Registering DLL Question - Part 2
- Next by thread: Re: Registering DLL Question - Part 2
- Index(es):
Relevant Pages
|
