Re: Server Access via DCOM
- From: DR Bellavance <DRBellavance@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 23 Oct 2006 06:19:02 -0700
Thanks for your reply. I suspected that this was the best way to get the
access to work. If I have to set a property, can I do this any other way
other than setting the text for the object in the html page? Some form of
global property setting in the IE control? I am a newbie when it comes to
embedded controls so please bear with me.
Thanks,
--
DR Bellavance
"Brian Muth" wrote:
Makes complete sense. Seems straightforward to me that the ActiveX control.
needs a property indicating which server to connect to. The value of this
property can be embedded right into the html page, as in:
<object classid="clsid:E135E5CE-BE57-4DC8-B49B-0B6DFC6FEA71"
id="adcActivate"><param NAME="Server" VALUE="Server14">
</object>
Obviously your ActiveX objects needs to support the IPersistPropertyBag
interface. It possibly already does.
Brian
"DR Bellavance" <DRBellavance@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:268FDC35-CFC2-4C94-A391-06AAD978006B@xxxxxxxxxxxxxxxx
The object is an ActiveX button control with a property that when pressed,
calls a method in the server passing the value of the property causing the
server to perform the service on the target machine (in this case, I
perform
functional tests on the target). I've got html pages with multiple
instanses
of the control embedded on them, each instance has a different property
setting that tells the server to perform a different test depending on
which
ActiveX control gets pressed. The client is a dialog application that
contains an IE control that loads the html page containing the ActiveX
button
controls (there are many html pages that are loaded into the IE control,
which page is loaded depends on the results of the test). I would like to
be
able to start multiple instances of the client application and connect
each
one to a different machine (each running an instance of my server). When
the
client application loads the html page with the embedded ActiveX buttons,
how
can I tell the buttons which server to talk to (ie. one client instance is
talking to a server on machine A and another client instance is talking to
machine B)?
Does this make more sense?
Thanks,
--
DR Bellavance
"Brian Muth" wrote:
"DR Bellavance" <DRBellavance@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BF6AFE67-D0B7-48C8-80AC-0D40307F77C3@xxxxxxxxxxxxxxxx
I am trying to create a client that can list all of the systems on a
network
that contain my ATL server and allow them to select and connect to the
server
on the machine that they want. I am using VC 6.0 and all of the
machines
are
running XP Pro. My client is also using the IE control and the server
sends
events to the client that cause the client to load the appropriate HTML
page
in the control. This all works fine but I have a problem when I want
to
launch another instance of the client application to connect to my ATL
server
on a different machine. The problem lies in the fact that I have
embedded
ActiveX controls (written in ATL) on the html pages that are loaded by
the
server. These controls provide function activation on the server that
I
am
connected to. How can I get the controls on one client application to
access
the server on a different machine than the one being accessed by the
second
client instance? Any help would be greatly appreciated.
Using CoCreateInstanceEx() from within your ActiveX control (is it really
an
ActiveX control or is it a simple COM object?) you can reach any machine
by
machine name or IP address.
Or did I not understand your question correctly? I'm not sure where the
"second instance" comes into play.
Brian
- Follow-Ups:
- Re: Server Access via DCOM
- From: Brian Muth
- Re: Server Access via DCOM
- References:
- Re: Server Access via DCOM
- From: Brian Muth
- Re: Server Access via DCOM
- From: DR Bellavance
- Re: Server Access via DCOM
- From: Brian Muth
- Re: Server Access via DCOM
- Prev by Date: Re: Oops, actually a debug/release issue, not VS 2003/VS 2005
- Next by Date: Re: Server Access via DCOM
- Previous by thread: Re: Server Access via DCOM
- Next by thread: Re: Server Access via DCOM
- Index(es):