Re: Register DLL Question
- From: "Someone" <nobody@xxxxxxx>
- Date: Wed, 19 Oct 2005 18:05:15 -0400
> I actually was thinking to switch to Delphi.
Delphi can create EXE's with minimum dependency, like C++, but VB's syntax
is more easily read than Delphi(Delphi uses Begin/End keywords for every
block of code).
InnoSetup was written with Delphi and has no dependency, just like Notepad.
> So... back to the topic... do I good to go not to register the DLL/OCX?
> or back to the original topic. Do I have to register OCX/DLL in order for
> my program to work?
In English, OCX/DLL files must be registered before using them. If I am
reading MSDN correctly, ".local" trick don't work on ActiveX/COM components
with broken binary compatibility because you can't have 2 different set of
registry keys for the 2 DLL's simultaneously(The old and new DLL). There
isn't enough documentation. If MS is supporting this for ActiveX/COM
components, they have to redirect the registry as well, but the
documentation doesn't show anything about registry redirection.
The ".local" trick will load the alternative DLL, but will not register it
when the EXE is opened as far as I understand the documentation. If you
register this new version of the DLL and it's not compatible with older
versions then you will break older version of your applications unless you
recompile them and send them to your customers.
".local" comments in MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_library_redirection.asp
You may want to check with the 3rd party vendor to see if they have any
suggestions or published bug reports.
If I were you, I would do one of the following:
1 - Use the old DLL: Uninstall the new incompatible DLL/OCX from my
development machine and make sure that the DLL/OCX was deleted, if not,
delete it manually. Never delete an ActiveX file without unregistering it
first by either uninstall or manually unregister it. Now install the older
DLL and recompile your application, no need to recompile applications that
already use the old DLL. At the end user, the user must unregister the new
DLL and make sure that it was deleted, then reinstall your new app which
uses the old DLL.
2 - Use the new DLL(Recommended): Make sure that you have the latest version
on your development machine, then recompile all of your applications that
use this DLL. Tell the end users to uninstall all of the old Apps first,
then install the new package.
If the DLL/OCX that you are using is widespread, and the user has an old App
that was made by a 4th party, then that application will stop working if it
uses that DLL. You, yourself could be that 4th party if the user had no
problems at all, then updated one application which updated to incompatible
DLL, in that case, all of your apps that use that DLL will stop working and
the user would blame you, when it's the DLL/OCX vendor's fault. But as far
as the user is concerned, you are one unit.
"boaz" <nospam@xxxxxxxxx> wrote in message
news:OpwJ8vO1FHA.460@xxxxxxxxxxxxxxxxxxxxxxx
>I will say about 50% like my products and 10% doesn't like it, and about
>40% doesn't care.
>
> And I don't worry about intallation problem. Many of my customers have a
> big IT department. Many of them know what to do. Many of them don't.
> The real problem is that "updating" (of any kind) for them is a big deal.
>
> I actually was thinking to switch to Delphi. But the same problem came
> back. I couldn't sell the stuffs if I told them it was written in Delphi.
> I had to tell them that it was Microsoft and MacroMedia, and craps like
> that.. So, the guys who were resposible for purchasing knew my craps were
> good craps. ;-)
>
> So anyway... according to "Someone", using ".local" may (and just may) not
> do the trick. I look at my projects, I don't have any custome dll at all.
> And the third party OCXs don't have any dependency (according to them).
>
> So... back to the topic... do I good to go not to register the DLL/OCX?
> or back to the original topic. Do I have to register OCX/DLL in order for
> my program to work?
>
>
>
>
>>
>> (does this mean that YOUR s/w is crap because it's not from a well-known
>> brand name ? (going by your logic) i'm sure you would take offense to
>> that.)
>
>
.
- Follow-Ups:
- Re: Register DLL Question
- From: boaz
- Re: Register DLL Question
- From: boaz
- Re: Register DLL Question
- References:
- Register DLL Question
- From: boaz
- Re: Register DLL Question
- From: Ralph
- Re: Register DLL Question
- From: Jim Carlock
- Re: Register DLL Question
- From: boaz
- Re: Register DLL Question
- From: DanS
- Re: Register DLL Question
- From: boaz
- Register DLL Question
- Prev by Date: OT: Re: Register DLL Question
- Next by Date: Re: Register DLL Question
- Previous by thread: Re: Re: Register DLL Question
- Next by thread: Re: Register DLL Question
- Index(es):
Relevant Pages
|