Application object in ActiveX DLL

[Anonymous]

I know this question or a very similar one has been asked here before, but I thought
perhaps some new information might be available.

When you create an ActiveX DLL, it has an implicit Application object (presumably the
ActiveX client into which the DLL is loaded). This relationship seems to break down
somewhat when multiple sessions of AutoCAD are running, however.

For example, I have an ActiveX DLL (created with VB6) which contains some utility
functions. I reference this DLL from several VBA projects. If I run one of these VBA
macros in one session of AutoCAD, the prompts from my utility functions (contained in the
DLL) show up in another session.

If I create a property in my DLL to hold a reference to an instance of AcadApplication and
then initialize it manually by passing Application from my VBA project, the problem goes
away.

'In my class module
Private objApp As AcadApplication

Public Property Set Application (ByRef Application as AcadApplication)
Set objApp = Application
End Property

'In my VBA macro
Dim objUtil As New Utility

Set objUtil.Application = Application

It seems kind of backward to do this, since a default Application object is provided to
the DLL.

If anyone has any insight into why this behavior occurs, it would be greatly appreciated.

Thanks,
Chuck Gabriel
Coggin Carrara, Inc.

[Anonymous]

The root of the problem is the way GetObject works. Every instance of
AutoCAD is registered in the ROT (Running Object Table). GetObject merely
gloms on to the first instance it encounters, even if there are multiple
instances.

To get around this problem, you must revoke each instance in turn until you
find the one you want then re-register all the revoked ones. Unfortunately,
this requires C++ and I have never learned how to do it.

This feature was available in AsdkUnsupp.arx but I don't know if it still
exists in AsdkUnsupp2000. Even so, I'm not quite sure where to find it. You
might try Randall Rath's site (www.vbdesign.net)

--
http://www.acadx.com
"That's no ordinary rabbit"


"Chuck Gabriel" wrote in message
news:4AED07535E944975C571FB058F04F054@in.WebX.maYIadrTaRb...
> I know this question or a very similar one
> has been asked here before

[Anonymous]

Hi again Chuck, here's my .02 which you've already heard...

Microsoft says you can hook into a running instance of an app with the
syntax:

GetObject("ActiveDocumentName").Application

At a glance this looked bizzare, and I could only get it to work, maybe 1 in
10 times, and only if the document name I specified was active in the oldest
instance of the app. The rest of the time I'd get an automation error. IF
anyone else has got this syntax to work I'd like to know how!

Regards,
Jacob Dinardi

"Chuck Gabriel" wrote in message
news:4AED07535E944975C571FB058F04F054@in.WebX.maYIadrTaRb...
> I know this question or a very similar one has been asked here before, but
I thought
> perhaps some new information might be available.
>
> When you create an ActiveX DLL, it has an implicit Application object
(presumably the
> ActiveX client into which the DLL is loaded). This relationship seems to
break down
> somewhat when multiple sessions of AutoCAD are running, however.
>
> For example, I have an ActiveX DLL (created with VB6) which contains some
utility
> functions. I reference this DLL from several VBA projects. If I run one
of these VBA
> macros in one session of AutoCAD, the prompts from my utility functions
(contained in the
> DLL) show up in another session.
>
> If I create a property in my DLL to hold a reference to an instance of
AcadApplication and
> then initialize it manually by passing Application from my VBA project,
the problem goes
> away.
>
> 'In my class module
> Private objApp As AcadApplication
>
> Public Property Set Application (ByRef Application as AcadApplication)
> Set objApp = Application
> End Property
>
> 'In my VBA macro
> Dim objUtil As New Utility
>
> Set objUtil.Application = Application
>
> It seems kind of backward to do this, since a default Application object
is provided to
> the DLL.
>
> If anyone has any insight into why this behavior occurs, it would be
greatly appreciated.
>
> Thanks,
> Chuck Gabriel
> Coggin Carrara, Inc.
>
>