...OF COM+ and ACTIVEX EXES.... (:-)

Hello people. I want to encapsulate my com object as an activex exe so it can run outside of the calling process. Some of the functions are processor intensive and can sort of make the gui unresponsive. I want to put the functions in a diff thread. I'm using vb6 so I can't use the straightforward multithreading features of vb.net.

In fact what I would like to build is a client server application. Such that a database and the com exe reside onthe same machine. and client machines simply connect to it and do their thing....

Exactly how will my activex exe be run? in COM+, will I use a shell command to start it up...?
Please help soon.
Thanks

Comments

  • : Hello people. I want to encapsulate my com object as an activex exe so it can run outside of the calling process. Some of the functions are processor intensive and can sort of make the gui unresponsive. I want to put the functions in a diff thread. I'm using vb6 so I can't use the straightforward multithreading features of vb.net.

    Then give up ActiveX EXEs. Since they run as out-of-process components, they'll be way slower.
    My two cents: build an ActiveX DLL for the "engine", AND a standard exe for the GUI.
    Multithreading in VB6 is possible as long as you don't have any user interface messing things up. Otherwise, you'll face dozens of unpredictable blue screens. Even on Win2k.
    You could rather use the dreaded "DoEvents" in the heavy functions, instead. It sort of simulate multithreading, when used this way.
    In the end, a DoEvents call is just the same as "context switching", more or less.

    : In fact what I would like to build is a client server application. Such that a database and the com exe reside onthe same machine. and client machines simply connect to it and do their thing....

    That's what COM+ is built for. Make an ActiveX Dll, register it on the server (from the control panel), create a "package" (same application you use to register COM+ Dll) and install this package on the clients.
    Or, redesign things to keep processing on the client.
    After all, if a function is heavy, you want to process it on a client, and slow the client, instead of processing it on the server, slowing the server *along* with all the clients waiting for it. Again, my two cents, but I think it's logical (fat client-thin server two-tiered application model).

    : Exactly how will my activex exe be run? in COM+, will I use a shell command to start it up...?

    More or less as a service. You install the DLL (or EXE), register it with RegSvr32, then from the command panel thingy (Component Services, on some Win versions) you register it as a COM+ component. From then on, you can call it from VB code.
    Just use "CreateObject" instead of "new", like this:

    [code]
    Dim MyObject as CMyObject

    'wrong way
    Set MyObject = new CMyObject

    'right way
    Set MyObject = CreateObject("MyLib.CMyObject", RemoteServer)
    [/code]

    where "RemoteServer" is a string containing the WINS server name (its plain machine name). Once you do this, calling any property/method on MyObject will issue a request to the server.
    Nothing else is involved, if I'm not wrong.
  • : : Hello people. I want to encapsulate my com object as an activex exe so it can run outside of the calling process. Some of the functions are processor intensive and can sort of make the gui unresponsive. I want to put the functions in a diff thread. I'm using vb6 so I can't use the straightforward multithreading features of vb.net.
    :
    : Then give up ActiveX EXEs. Since they run as out-of-process components, they'll be way slower.
    : My two cents: build an ActiveX DLL for the "engine", AND a standard exe for the GUI.
    : Multithreading in VB6 is possible as long as you don't have any user interface messing things up. Otherwise, you'll face dozens of unpredictable blue screens. Even on Win2k.
    : You could rather use the dreaded "DoEvents" in the heavy functions, instead. It sort of simulate multithreading, when used this way.
    : In the end, a DoEvents call is just the same as "context switching", more or less.
    :
    : : In fact what I would like to build is a client server application. Such that a database and the com exe reside onthe same machine. and client machines simply connect to it and do their thing....
    :
    : That's what COM+ is built for. Make an ActiveX Dll, register it on the server (from the control panel), create a "package" (same application you use to register COM+ Dll) and install this package on the clients.
    : Or, redesign things to keep processing on the client.
    : After all, if a function is heavy, you want to process it on a client, and slow the client, instead of processing it on the server, slowing the server *along* with all the clients waiting for it. Again, my two cents, but I think it's logical (fat client-thin server two-tiered application model).
    :
    : : Exactly how will my activex exe be run? in COM+, will I use a shell command to start it up...?
    :
    : More or less as a service. You install the DLL (or EXE), register it with RegSvr32, then from the command panel thingy (Component Services, on some Win versions) you register it as a COM+ component. From then on, you can call it from VB code.
    : Just use "CreateObject" instead of "new", like this:
    :
    : [code]
    : Dim MyObject as CMyObject
    :
    : 'wrong way
    : Set MyObject = new CMyObject
    :
    : 'right way
    : Set MyObject = CreateObject("MyLib.CMyObject", RemoteServer)
    : [/code]
    :
    : where "RemoteServer" is a string containing the WINS server name (its plain machine name). Once you do this, calling any property/method on MyObject will issue a request to the server.
    : Nothing else is involved, if I'm not wrong.
    :

    Thanks a mil stefan. Your "two cents" clarified things for me quite nicely..
    I'm going to look into that. I guess the most pertinent use that the com+ package can be used for is extracting data in a secure manner. Say, if one uses an application role in SQL server to ensure that only the application can talk to the SQL.
    Then functions that manipulate the data occur only on the client. Updates are then sent to the server COM+ dll which handles actually updating the data.

    All the best people. Peace
    It makes more sense to me now...
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories