Re: Early Binding Fails
Douglas Marquardt
You need to be more specific -- exactly what is the error?
In any case, because you can create the object but early
binding it fails, I suspect that the dll on the problem machine
is either not the latest version, or not physically the same one as
on the machine the works?
Doug.
"Jiju Joseph" <JijuJ...@discussions.microsoft.com> wrote in message news:39C6381C-8F5A-4E9A...@microsoft.com...
> Hi,
>
> I have a Piece of code as following,
> Dim oF As prjFunction.clsFun
> Set oF = CreateObject("prjFunction.clsFun")
>
> Which bombs when running on one machine, If I Declare oF as Object,
> it works fine, (Don't tell me its because of wrong Reference, I am 100% sure
> that the Reference are correct - Because the DLL's deployed on another
> machine is working fine.)
>
> Can anyone tell me whether this is dependent on some windows files??
> What is the reason that the machine is not supporting Early Binding.
>
> Thanks in Advance
> Jiju Joseph
Jiju Joseph
The issue, If I use Early Binding, the COM throws an Error "Error in
loading DLL", And I did cross verify the DLL's on the working box & problem
box, same version, same size, same creation date.
I even copied the Dll from the working box, still the same issue.
Regards
Jiju Joseph
Ken Halter
> Hi Douglas,
>
> The issue, If I use Early Binding, the COM throws an Error "Error in
> loading DLL", And I did cross verify the DLL's on the working box &
> problem
> box, same version, same size, same creation date.
>
> I even copied the Dll from the working box, still the same issue.
>
> Regards
> Jiju Joseph
Check the dependencies for that DLL. Even though the DLL may be "fine", what
ever it needs to run may be missing.
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..
Jiju Joseph
If the DLL has Depends Problem, it will not work even if you use late
binding, But the DLL is working while done through Late Binding.
Regards
Jiju Joseph
Schmidt
"Jiju Joseph" <JijuJ...@discussions.microsoft.com> schrieb im Newsbeitrag
news:A100745A-19EE-4A55...@microsoft.com...
> If the DLL has Depends Problem, it will not work even if you use late
> binding, But the DLL is working while done through Late Binding.
One additional idea, what you could try next.
Test, if you can instantiate your Class (early-bound) without using the
registry:
Standard-Dll-Helper is needed (DirectCom.Dll from)
www.datenhaus.de/Downloads/dh_DirectCom.zip
Put the Dll into your App.Path and declare this Call:
Private Declare Function GETINSTANCE Lib "DirectCom" _
(FName$, CName$) As Object
Then you can change your instantiation-Line to:
Dim Obj as clsFun
Set Obj = GETINSTANCE(FileName, "clsFun")
If that works, then there are definitely wrong registry-entries at your
Problem-PC.
Olaf
Someone
the keys mentioned in the following article:
PRB: DCOMCNFG Reports Multiple Copies of DCOM Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;180525
Even if you don't have multiple copies of the same ActiveX in the registry,
the steps above still apply. They are equivalent to "regsvr32 /u
control.ocx", or "regsvr32 /u <vbide>".
A registry cleaner utility might do this for you if you delete your ActiveX
file, but I am not sure.
Note that the article refers to using DCOMCNFG.EXE in Windows 9x. You can
see the same list of objects by going to Project|References. In newer
versions of Windows, you can see the list of objects in Control
Panel|Administrative Tools|Component Services|Computers|My Computer|DCOM
Config. Typing "DCOMCNFG.EXE" will open "Component Services". You might see
some warnings that some AppID's are not recorded, choose No.
When you run an ActiveX project in the IDE, VB6 creates registry entries and
points them to the following file:
C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL
When you stop the project, the IDE would auto delete these entries, unless
it crashes. When you compile your ActiveX project, VB6 auto create the
registry entries for them and point them to your compiled file. VB6 never
delete these entries, otherwise you can't use your component.
Also, in NT, you have to be a member of Power Users or Administrators in
order to develop and test ActiveX projects. That's because only Power Users
and Administrators can write to HKEY_LOCAL_MACHINE.
INFO: Registry Entries Made by an ActiveX Component
http://support.microsoft.com/default.aspx?scid=kb;en-us;183771
"Jiju Joseph" <JijuJ...@discussions.microsoft.com> wrote in message
news:2C3A609D-5C3C-4E0C...@microsoft.com...
Martin de Jong
Maybe you changed the DLL - interface so a new CLSID is generated and used.
Martin
"Jiju Joseph" <JijuJ...@discussions.microsoft.com> schreef in bericht
Richard Jalbert
<JijuJ...@discussions.microsoft.com> wrote:
>Hi,
>
> I have a Piece of code as following,
> Dim oF As prjFunction.clsFun
> Set oF = CreateObject("prjFunction.clsFun")
I think the correct syntax for tat call is
Set oF =
CreateObject(<applicationname>.<public-routine_that_Is_the_entry_point
into your COM)
I used to call all the entry pointa "Application"
Set oF = CreateObject("myDLL.Application")
> Which bombs when running on one machine, If I Declare oF as Object,
>it works fine, (Don't tell me its because of wrong Reference, I am 100% sure
>that the Reference are correct - Because the DLL's deployed on another
>machine is working fine.)
>
> Can anyone tell me whether this is dependent on some windows files??
>What is the reason that the machine is not supporting Early Binding.
>
>Thanks in Advance
>Jiju Joseph
=====================================================
This is not a signature, it is an honour virus:
copy it at the bottom of all your e-mails.
rich...@sympatico.ca
=====================================================