Printable View
I am having a little problem fully understanding the instancing property of ActiveX COM components. The instancing property has these to choose from:
1-Private
2-PublicNotCreatable
3-SingleUse
4-GlobalSingleUse
5-MultiUse
6-GlobalMultiUse
I have read a bunch of technical jargon about these, but havent found a source that puts each of these with a real world example of why I would use it.
So what I need is you guys to explain them in simple terms for me to understand.
What happens is the SCM maps process memory to the dll code or makes a connection to the activex exe process for each instance of an object.
What these choices do is to control how the threads and ActiveX Exe processes work. Or even if threads are created at all.
Some are used for activex exe running in a separate process, others for dll's.
Private - this means that only the COM object's own code can see the object. You cannot map it from any external code. This is like COM's very own 'pet' COM. All methods and properties are abstracted (hidden) from the client.
PublicNotCreatable - This means that this particular object can be seen ONLY after another related object has been instanced beforehand by the client. You can't use New of CreateObject on this guy. Assumes that some other code (part of another control) must be running in order for this to work, or used if you don't want somebody to be able to access it without it's related COM objects having been created, too.
MultiUse - the default setting. Means after you create one instance the other cousin objects created (like in an array of controls) all share most code. Their properties are abstracted (protected) from all of the other cousins. Very efficient.
GlobalMultiUse --Same as MutliUse except that the functions are now accessible globally from client code. ie., one COM object can invoke another's functions(methods). The functions are not abstracted from one another.
Singleuse - means each instance is created in it's own process rather than in a thread, so if you had an array of conrols like this, there will be a corresponding unique process for each object. ActiveX Exe type thing only. Resource intensive, usually run on db servers kind of thing.
GlobalSingleUse - like singleuse with the extra added feature of globally accessible functions - ActiveX Exe, again
hth
Ok, I am *starting* to become more clear on them, see if I got it right:
By your explaination, for ActiveX Dll's I will most likely be using Private for my internal objects, and MultiUse for my objects that the user is going to instantiate in their code, is this right?
By the same token, for ActiveX EXE's, I will be using SingleUse mostly because more than one program will be accessing them at one time, and it would be quicker for each client to have their own instance, although more server resources are going to be used?
Are these right?
More questions came to mind on this subject though. Where does the threading model and thread pools come into play? Which setting is most scaleable in terms of ActiveX EXE's?
Thanks for your help.
Correct.Quote:
By your explaination, for ActiveX Dll's I will most likely be using Private for my internal objects, and MultiUse for my objects that the user is going to instantiate in their code, is this right?
Yes.Quote:
By the same token, for ActiveX EXE's, I will be using SingleUse mostly because more than one program will be accessing them at one time, and it would be quicker for each client to have their own instance, although more server resources are going to be used?
Are these right?
Apartment model threading is how code and data become abstracted. In a control array, you have properties for each object. If you change one object you don't want all the others to reflect the same change. Necessarily.
Scalability is what DCOM is all about. In the PC world, networks are how you get more bang for a buck. MTS and DCOM are there to allow just that. You use ActiveX Exe instancing in either flavor, without much impact on performance.
Since you seem to be COM-ing from VB only, where everything is hidden from view, consider reading VB COM by L Thomas. It's the only COM book for VB that's readable and not part of MSCD, which isn't readable. IMO. In fact, understanding what the heck VB is doing behind your back is pretty hard. Which is why so many VB programmers don't fully understand COM.
To actually learn interfaces, threading, and so on, you have to mess around with COM in C++. Again IMO. In C++ you can see it all, no 'footsie' behind your back. Plus COM-ponents built in C++ are a generally a lot smaller resource-wise than the same stuff coded in VB. If you're worried about performance that much.
Thanks for all your help. I have read the VB COM book by Thomas Lewis, but went pretty fast over it. I guess I never let it sink in to well.
I think I will go look for a book or something for C++ and COM. I have worked a little with C++ (got the basics anyway) so maybe it is time I start to develop that as well.
Again, Thanks for all your help.