|
George_George wrote: Do you mean retrieve the object instance directly compared retrieving the object instance by proxy?
No I mean retrive the object instance directly compared to recieving a proxy for the object generated especially for you. ( This often happens with connection points )
George_George wrote: Any more description please?
There are endless permutations and complication within COM and many of the rules can be 'bent' to meet extremely strange configurations at the server end. Part of the point of COM is that you don't have to know or care, play it by the book from your end and the rest will either work or it won't. The reality can sometimes be more complex but usually only because somebody somewhere broke the rules. 
I once retrofitted a large MFC/MDI multithreaded desktop application so that it could also be launched remotely as a DCOM server with no visble UI but fully functional. Had to rework virtually the entire MFC Doc/View startup process to make it work under both conditions but COM wise it was all within the rules and the middleware using it as a backend was none the wiser. So cool when it worked. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Cool, Matthew!
Why aggregation is used, for the same COM object, different interface pointer binary values could be retrieved? Any more description please?
regards,
George
|
|
|
|
|
Again it's nothing specific to aggregration but an aggregate outside might choose to hand out a pointer to a different inside instance. One case where this might happen is where an aggregate is used to disguise a single threaded object as apartment threaded by creating multiple instances, once for each thread that enters the appartment. As I said almost anything is possible with enough ingenuity.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Matthew Faithfull wrote: One case where this might happen is where an aggregate is used to disguise a single threaded object as apartment threaded by creating multiple instances, once for each thread that enters the appartment.
Looks cool. Your experience is so rich, I have never written code like that before. All the aggregation code I wrote before is about returning the pointer for the outer object when client requests for the inner object interface pointer through outer object's QueryInterface.
Now I understand the implementation is very flexible, and I should not stick to one fixed form.
regards,
George
|
|
|
|
|
As the saying goes 'experience may vary', just because I got away with something once using an old version of ATL on VC6 doesn't mean it was ever a good idea or that you should be using it as a design guide. Coming up with ways to meet the spec, usually on the cheap and often wihtout a spec in the first place, that's what commercial software dev has always been about  On the other hand if you're just experimenting for fun then I'd say go for it, try anything once, even if it doesn't work at all you'll learn something new. Good luck.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Just want to make a final confirmation that, COM does not require query for interface for the same COM object returning for the same binary value, so even if we implement the way as you mentioned in the cool sample for thread-per-object-instance, the implementation does not violates the COM standard?
regards,
George
|
|
|
|
|
If I remember my COM lore rightly then that is the case, it only requires that if you do return the same value it represents the same object but the only time it would be useful is if you're aggregating an existing object which is single threaded and you can't change it. Performance is likely to be mediocre at best with all the calls going from the MTA into separate STAs.
On the other hand a single front object for multiple internal objects, all of which can live in the MTA is a very reasonable and potentially useful design. The single coolest component I've ever designed was a little piece of middleware, an ATL Singleton which operated an internal thread pool for handling requests from multiple ASP Web Servers, each request was simply forwarded to the correct back end application instance according to the session ID of the Web user. This solved the persistent user state issue that prevented IIS being properly scalable for years. All old hat these days of course.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Cool, Matthew!
1.
Matthew Faithfull wrote: On the other hand a single front object for multiple internal objects, all of which can live in the MTA is a very reasonable and potentially useful design.
I think you mean making an MTA thread/component as front end and STA as inner component, and communication between MTA and STA through marshalling, right?
2.
For the performance design you mentioned above, if you say performence improved or superior, it must have some parties to compare to. What is the inferior design you compared to?
3.
"mediocre" you mean good or not good? Sorry for my limited English skill.
regards,
George
|
|
|
|
|
George_George wrote: an MTA thread/component as front end and STA as inner component
No that is the slower design because of all the interappartment calls.
George_George wrote: "mediocre"
means not very good.
If the inner components are free threaded but only ever called on the thread where they were created, by the outer component, then they all live in the MTA but don't have to worry about locking/synchronisation, you only have to do that in one place, in the outer component, plenty of speed and no deadlocks
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
1.
"interappartment calls." you mean marshalling expenses? And message queue expenses for STA?
2.
Let me repeat your great idea to confirm I understand.
You mean using MTA at front end, and using free threaded inner component for worker thread in MTA, right? Since in your design, each component is only touched by one thread, no synchronization and lock issues are needed to be considered and coded, so performance is improved, right?
3.
I am hard to believe such a system with separated components which do not need to share data has any values. In your designed system, the inner components do not need to communicate with each other? At least I think they need to communicate with the single MTA front end component, which there is additional locks on the MTA front end, which degrades performance.
Any comments?
regards,
George
|
|
|
|
|
George_George wrote: 1.
Yes.
George_George wrote: 2.
Yes.
George_George wrote: 3.
The system has value in limited situations such as if you're scaling a single user system up to a multi user system. If each inner component is tied to a one user and can work without much if any modification.
Yes you still need locks in the front end component as I said but only to protect the thread pool and this can usual be done with fairly efficient Critical Section locks. In the system I worked on the only 'communication' between the inner objects was that they shared a database. This was already protected for sharing anyway as it normally would be between multiple users.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
1.
Matthew Faithfull wrote: This was already protected for sharing anyway as it normally would be between multiple users.
You rely on database lock? So, if you rely on database lock, there is no need to add additional lock on your inner component.
2.
I did some research and find MTA component is the same as free threaded component, right? Why do you distinguish them in your previous posts?
regards,
George
|
|
|
|
|
Hi all,
I m using a image list for TreeView.
How can change icon of TreeView Item On the click of CheckBox or Double click on that purticular item.
Thanks in advance.
|
|
|
|
|
You have a few choices. You can use TVM_SETIMAGELIST, with wParam set to TVSIL_STATE. That should replace the actual checkboxes.
Or you can react to NM_CLICK / NM_DBLCLICK, and change the image list index for an item, which gives you added flexibility.
There's a lot of "depends", depending on the finer details of what you're trying to do.
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
Please can u give some example of code.
|
|
|
|
|
ThatsMe. wrote: Please can u give some example of code
Nope! There's several stages in there.
Look up ON_NOTIFY, and NM_CLICK to write a handler to monitor for clicks.
Then TVM_HITTEST to find out which item was clicked.
Then TVM_SETITEM, with a tvItem.mask = TVIF_IMAGE to change the image index to something else.
Lastly, You may need to invalidate the control.
This is a decent chunk of work, but like most programming jobs, break it into bite size chunks.
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
I need get icons 48x48 from system imagelist.
Function SHGetFileInfo can get list of icons 16?16 or 32?32.
But how I can retrieve 48?48?
This is needed for display list of disks in CListCtrl in view Tile...
|
|
|
|
|
Check out SHGetImageList()
|
|
|
|
|
hi
I have a application to display a message box after the application is closed . How can i do that , help me .
with warm regards
K.Guru Moorthy
k.guru moorthy
|
|
|
|
|
Well, if your application is terminated, you can't do anything from it anymore.
You mean that you want to display a message box when the main application window disapeared ? If yes, which kind of application are you doing ? SDI, MDI, dialog based ?
|
|
|
|
|
hullo sir, thanks for replying. it is a vc++ applikason.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
(1) Display the message box when your application is still running.
(2) Press down the Print Screen key on the keyboard.
(3) Close your application.
(4) Open MS Paint.
(5) Paste the image ( CTRL + V ).
(6) Enjoy you Message Box 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Create a service which monitor your application and call a MessageBox from your service whenever your application is closed.
|
|
|
|
|
Hi,
Try handling the WM_QUIT message in the application main window. Here you show a messagebox using ::MessageBox API with NULL window handle.
case WM_QUIT :
MessageBox(NULL,"Your Message","Your Message Caption",MB_OK);
i think this will help you.
thanks.
Nitheesh
|
|
|
|
|
Or When you want to exit your program you can run other exe file for show it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
