Re: VB newbie - exposing VB subs to VBA?
From: Ralph (msnews.20.nt_consulting32_at_spamgourmet.com)
Date: 02/15/05
- Next message: Ken Halter: "Re: simple form float on top - or timer in task bar"
- Previous message: Vinícius Gonzaga: "Transact SQL"
- In reply to: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Next in thread: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Reply: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 15 Feb 2005 08:32:14 -0600
"Maury Markowitz" <MauryMarkowitz@discussions.microsoft.com> wrote in
message news:49E748D9-84DE-4AD6-A8BD-EFA5A1643AB2@microsoft.com...
> "Ralph" wrote:
> > There is no way to avoid 'DCOM', per se, as you will have to create an
> > ActiveX component and use COM to connect to it. Using either an ActiveX
DLL
> > or EXE. Excel is an example of an ActiveX Exe. You would 'connect' to
your
> > component the same way.
>
> That's fine: the problems that I'm seeing are likely due to the
applications
> themselves, as opposed to DCOM. This is why I'm interested in the VB path,
> because that way I feel I can have more control over the process.
>
> > To create one in VB is very simple, just chose the correct Project
Wizard
> > when you create the project. Then make sure the component is properly
> > registered on each box and configured thru the Computer Managment
Console
> > (MMC, Component Services Admin, ..., or whatever for your platform).
>
> Is there any way to automate this process? For instance, can VB code call
> whatever is needed to complete the registration?
>
> > Not sure what you mean by "fire up a command line app from a remote
> > machine". There are various ways to run a remote shell on another
computer
>
> This is precisely what I mean. Is there something "built in" that I should
> be aware of?
>
> > user. You might want to look at the various COM+ services such as
messaging
> > for a more easily controlled cross-box communication. But this likely
> > over-kill for what you are trying to do.
>
> I also considered SOAP, but setup for many of these sorts of systems tends
> to be difficult -- or at least more difficult than DCOM.
>
> Maury
I doubt if I totally understand your problem domain. But let's see if I can
come close. <g>
First of all 'DCOM' as I am sure you know has been expanded and placed
within the COM+ realm which is now pretty much rolled into the O/S. The
whole idea of dcom is to allow one to use services from any box - they are
distributed. Using COM+ is rather simple, in that you just register a
component on a box and then create a register entry for that component on
other boxes signifying where a program/process can 'find' that component. Or
you can indicate during a call where the component should be located, eg,
"Set App = CreateObject("Excel.Application", "SomeServer")".
You can use various means to 'automate' the setup or configuration of COM
components - manually using the various Computer Managment tools, siliently
using .reg files, scripts, mis scripts, etc. COM services/servers are
simplicity in themselves.
An ActiveX Exe 'automatically' registers itself when it is run the first
time. ActiveX DLLs can be 'automatically' registered when they are
installed. (You should always install a com component.)
In the early days, and many books on COM will still demo these examples, you
were pretty free to run things practically any where and any way you
wanted - all you needed was a basic trust relationships between the two
boxes. If you can 'see' it, you can call it. Everyone tended to take a few
short-cuts. Programmers pretty much set things up as they saw fit or their
programs required.
The problem is that COM has been abused and become a security hole. XP and
the various security patches have really clamped down (depending on admin)
on their use. Most of the short-cuts have been (or should be eliminated),
that is why COM setup appears more complex than it really is. It needs to be
controlled. There are few short-cuts left. All of which means you do have to
go thru (or should have to go thru) the admin toys setup to manage it.
Rsh and the other toys have suffered the same fate.
As programmers we often think of just our little world, our little
component, our little call, but allowing any kind of box-to-box
communication is really a domain or admin problem. That is why using the
basic services of COM+ (or WebServices, or ...) is an enterprise-wide
decision. And should be managed at the domain/enterprise level. Setting up a
COM+ messaging services, MTS, data-share, TS, etc. may seem over-complicated
for one little project. But once the mechanism is setup and a general
'mysolution' protocol is created, you will discover more and more
applications that can likely use the service.
Message servers are probably the best example of this. The first one is
always a bit of pain (just as anything new is always a bit of an adventure),
and everyone thinks of it as a particular 'nail' that solved "this little
problem", but every time I return to a site that originally set one up to
handle a minor little solution - I find a host of apps chattering away at
each other. It soon becomes a hammer. <g>
But back to your original question. Just create an ActiveX component. Place
it were you need it. Register it. Then call it. It should work unless your
admin is incrediably parnoid. <g> In which case use an O/S backed COM+
service.
hth
-ralph
- Next message: Ken Halter: "Re: simple form float on top - or timer in task bar"
- Previous message: Vinícius Gonzaga: "Transact SQL"
- In reply to: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Next in thread: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Reply: Maury Markowitz: "Re: VB newbie - exposing VB subs to VBA?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
