|
You're right.
Anyway, ask George_George, repetita iuvant 
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
|
|
|
|
|
hehehehe
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
it is crushing at this statement, pls advice
string abc,xyz;
ShellExecute(0, _T("open"), _T(abc.c_str()), _T(xyz.c_str()), 0,SW_SHOWNORMAL);
|
|
|
|
|
Why the strings are empty?
BTW You cannot use _T() macro that way.
What do you intend to do?
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
modified on Friday, April 4, 2008 10:00 AM
|
|
|
|
|
not strings are not empty, it executes the statment sucesfully and then gives
---------------------------
Navigator
---------------------------
A structured exception has occurred: Access violation
---------------------------
OK
---------------------------
after clickinig ok it simply crushes
|
|
|
|
|
it crashes just at the } closing for the function
|
|
|
|
|
Hi,
Do you have any idea, how to set the focus on the NO button (by default will be on YES button) in a AfxMessageBox of type MB_YESNO??
Priya Sundar
modified on Friday, April 4, 2008 8:28 AM
|
|
|
|
|
They hide that info in the documentation:
The following message-box styles are available.
Message_Box Types
<snip>
Message-Box Modality
<snip>
Message-Box Icons
<snip>
Message-Box Default Buttons
MB_DEFBUTTON1 The first button is the default. Note that the first button is always the default unless MB_DEFBUTTON2 or MB_DEFBUTTON3 is specified.
MB_DEFBUTTON2 The second button is the default.
MB_DEFBUTTON3 The third button is the default.
Judy
|
|
|
|
|
JudyL_FL wrote: They hide that info in the documentation
Well played 
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yes.
AfxMessageBox(_T("foo"), MB_YESNO | MB_DEFBUTTON2);
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
|
|
|
|
|
|
|
Can i use dll buil in .Net 2005 in Smart device project i.e. Win CE?
|
|
|
|
|
Only if your DLL was built for Win CE.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
No, you can't. A dll is similar to an exe for that: it is compiled code. You can't 'execute' that code on another platform. The same is true for ActiveX controls.
EDIT: hmm, like Rajesh tsaid, of course if it was biult for WinCE, then it's ok (I understood the question differently).
|
|
|
|
|
Hello everyone,
In the book ATL Internals, here is the description for CComVariant. My questions,
--------------------
COM permits an object to hand out different binary values each time a client queries it for a specific interface pointer (with the exception of a query for the IUnknown interface). Therefore, two VARIANTs containing IDispatch pointers referencing the same object might not compare for equality.
--------------------
1.
I think it means even if the pointer binary values are different, they may still be pointed to the same object? Right?
I think it happens only in the situation of multiple inheritance, and in single inheritance, there is no such issue. Right?
2.
I think the above statement describes the following scenario, in multiple inheritance, suppose we have interface A inherits from IDispose, and interface B inherits from IDispose, and have inteface C inherits from both A and B.
The queryInterface for A and B from interface C will return different result.
thanks in advance,
George
|
|
|
|
|
Nope, it has nothing to do with multiple inheritance, just the rules of COM that allow for transparent proxies and aggregation and all sorts of complex stuff. Each reference to an interface that a COM object hands out can be different because it might actually be refering to a different server side proxy. This doesn't really have much to do with VARIANTS and I don't think you need to worry about it. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Two more comments,
1.
Matthew Faithfull wrote: transparent proxies
I do not understand what do you mean? Do you mean retrieve the object instance directly compared retrieving the object instance by proxy?
2.
Matthew Faithfull wrote: aggregation
If an object instance is aggregated, it should only be queried from outer interface. I do not think for the same object instance, you can get two different interface pointer address? Any more description please?
regards,
George
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
