Help : GetObject and VB objects

I understand that this IUnknown exposes the properties of the object. I have seen that when using the CreateObject function,
I am getting a handle on the IUnknown of the specified class. Now what i'm looking to do is get two applications to link to the same instance of an object. ie one object creates the object and the other, using GetObject, uses the same instance of that object.

The result is that if the object has a value = 1, and app1 changes that value to 2, app2 also sees this change.

After some research i find i can't use GetObject with VB objects.
More research brings me to two OLE API calls; RegisterActiveObject - Inserting the handle into the ROT; RevokeActiveObject - Removing the handle from ROT.

To use these functions i need a handle to my objects IUnknown.
How do i get this?
:confused:

Wrong.

The basic idea of COM is that of a contract. You see only the interface. Client processes do NOT share common data. Just interface access. Never common data. Classes can do this in C - but they are not COM objects.

Each connection exists in it's own thread - so that two unrelated processes can use one object at a time, unmolested by changes they each make to the object.

COM is not used to share data between threads or processes.
You will be in a world of hurt later on, if you start trying to do stuff like that now. You will break your app bigtime.

If you want to share data or communicate or coodinate between threads or processes Use::

SendMessage with WM_USER (user defined messages)
Create atoms
Use named pipes or mailslots
Use mutexes, sempahores

These were invented just for that purpose.

DON'T USE COM.

Understood.

How then do i send messages between my applications using SendMessage?

This thread shows how to register your messages:

http://www.vbforums.com/showthread.p...message+WMUSER

You may need to have a system-wide hook. It traps all messages sent to the PC via the user interface. Use it with extreme caution.

Here's a discussion --

http://www.vbforums.com/showthread.p...ht=system+hook

Jim why do you say it will break your app big time to do this? I do this using an activeX exe to share user information among common programs, but after reading your post maybe I should change, tell me more. So far everything works peachy with no problems. Although I wouldn't suggest it accross a server.

I am not using GetObject just a connector object that connects to the same instance of a Public Not Creatable object.

It's analagous to GOTO. Can you use it? Absolutely. Should you - No. And you can give me 5 good reasons to avoid it, I'll bet.

If you understand classes, you know that there needs to be private members to do work inside the thread. These data items aren't visible to any external object, and are maintained separately in threads for each client. Apartment model threading.
Old news. This is the main idea of COM - classes with a binary interfaces.

According to COM theory, properties are thread-specific.
Having global properties is a no-no.

If you have a property that absolutely does nothing but gets read, you could expose it globally I suppose. But you could also put the same data in a file, a mailslot, or an atom just as easily. Lots less code, too.

As soon as the property is writable, you're definitely in a world of hurt. The behavior of the data is completely unpredictable, and uncontrollable.

The idea behind COM is complete black box - you see the interface, that's all. You don't know what goes on back there, you can't get to it. If you could get to it, you could very easily mess up another client's operations. That's what globally writable properties do. Violate the rules.

You can use marshaling to get data from thread A to thread B.
This stops the recipient of the data from affecting the data in the originating thread. Try that first.

Global properties offer no safety. They let anybody change the value whenever, regardless if another thread is using it. That's the why.

And since you can use about 10 other ways of creating interprocess communication from marshaling to SendMessage, why create something that has a data leak, as it's called?

Short answer: you can do it. But it'll get you one day. Just like GOTO. You'll decide to reuse some code that calls an interface, write something that doesn't follow your old rules, and you're merrily off right down into the pit.

Ok I kind of understand. The reason I ask is becuase you seem to have a handle on COM where as I am still learning. Although for my situation i want the properties and what not to effect all 'connected' clients and I want to be able to raise events through out all clients when certain actions are performed. I am using a shared ActiveX Exe as kind of like a passport type of program that holds the current user info for other programs in a suite. Do you think i should still move it to Send Messages or what not instead? I see your point about leaking in most cases.

Overall, your design may encounter problems, for example, if you expect only one specific client per node, for example. And somehow more than one shows up. Or, what happens if one user logs on to 2 different PC's and works a little at each one without logging off.

If you have your bases covered and it has worked for you - the CEO answer is: leave it alone.

You have to weigh labor costs in time coding, vs the potential cost in labor dollars for user problems and/or correcting programmatic damage to data. It comes down to how risk-aversive your shop is.

You decide that one.

But next time, you have an idea of where not to go.

Thanks fo the insight Jim.

Sharing data in COM is easy:

Send your reference pointer to the server (the Me object)

Get your server to implement that reference

Use that reference to callback

How hard is that?