ATL / WTL / STL

11-Jul-09 7:13

I am putting together a local COM server, which gets linked to a legacy static library. My server passes on notifications from this library functions to the client via connection point sinks (server has the Fire_xxx methods).

My problem is, the library author has freely used CreateThread()s in his functions, from which he triggers the notifications that I need to pass on to the client. As you guessed, this throws 8001010e HR. To get around this issue I used to register the interface ptr in GIT and getting it in the context of the thread. This trick wont work here, as with just the base interface, I am not able to touch all the Fire_XXX() functions!

How to get access to these? TIA.

Stuart Dootson11-Jul-09 7:30

11-Jul-09 7:30

Why not decouple the notifications from the Fire_XXX functions? Use an event, or similar to indicate to the COM thread that a notification has occurred (you can use some data to show what notification has occurred plus any parameters). Use a kernel wait in the COM thread to wait for the event to be signalled. When the event is signalled, call the appropriate Fire_XXX function.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan11-Jul-09 7:41

11-Jul-09 7:41

I thought of this...but, I am not sure how to apply this on my case..lemme explain: The server implements, lets say, "IServer" with a method "Run". I use "IServerEvents" to fire events in to connected sinks.

From IServer::Run(), I call one of the library functions, which does a CreateThread() and returns. So, my Run() returns a S_OK and things are all fine so far. But, when the thread started by the library function finishes its work and wants to notify the client, it calls a callback function my server had registered with it in the start. I call Fire_XXX() in this callback, which is not working as it is in the context of another thread...

Since my IServer::Run() has ended long time back, which COM context do I use?

Stuart Dootson11-Jul-09 7:52

11-Jul-09 7:52

What threading model does your local server use? Is it possible that using a multithreading model might enable your original design to work?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan11-Jul-09 18:23

11-Jul-09 18:23

I use MTA; Still the same issue. BTW, since the thread created by library function doesn't initialize COM, in my server callback I do a CoInitializeEx to COINIT_MULTITHREADED. From this callback when I try calling Fire_XXX (in the original server object, which is passed via a context param), I still get 8001010e.

Will creating a CWorkerThread/IWorkerThreadClient based thread automatically assume its parent thread COM context?

Stuart Dootson11-Jul-09 23:37

11-Jul-09 23:37

I presume you have managed to successfully call one of the Fire_XXX functions in tests or something? It's not that they just don't work?

Kannan Ramanathan wrote:
Will creating a CWorkerThread/IWorkerThreadClient based thread automatically assume its parent thread COM context?

I suspect you're more likely to know than me - I think you've donw a lot more COM than me. My comfort zone is mostly in-proc servers.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan11-Jul-09 23:43

11-Jul-09 23:43

Thanks Stuart for the reply.

Yes, Fire_xxx() events work correctly as long as they are called in the correct context.

BTW, I am trying out my good old GIT solution -- only this time I am going to store the sink interfaces in GIT and store the cookie in my vector...I am currently putting together a custom IConnectionPointImpl<> to store/retrieve things properly with out breaking anything;

Will update you how it goes...

Stuart Dootson11-Jul-09 23:47

11-Jul-09 23:47

The other suggestion I was going to make (but didn't get around to) was to start a long-running thread and use the event idea I first proposed within that thread.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan12-Jul-09 1:57

12-Jul-09 1:57

Custom implementation of IConnectionPointImpl<> to make use of GIT worked like a charm! Smile | :)

I'd seriously advise anyone stuck in a similar situation to try out this trick -- do let me know if you need my implementation (I think it shouldnt be a problem sharing my code, as it doesnt have any project specific details in it!)

Thanks Stuart for your replies.

Stuart Dootson12-Jul-09 5:48

12-Jul-09 5:48

Hint, hint - article -hint, hint. Smile | :)

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

VC6 problem: locale loc(locale::classic(), new myfac)

Member 348023215-Jul-09 0:51

Member 3480232

15-Jul-09 0:51

Much larger than just a hint. I, for one, have been fighting problems like this for a while now and would love to look at a different view than my own for a change. Thumbs Up | :thumbsup:

John R. Shaw9-Jul-09 20:51

John R. Shaw

9-Jul-09 20:51

Yes I am still supporting VC6 in this project and it has to be cross platform.

Buried in the VC6 MSDN Library under “locale::facet” is the line
“locale loc(locale::classic(), new myfac);”.

Which is correct for latter versions of the MS STL, but there is no locale constructor that takes a locale and a facet defined in the VC6 STL version of locale.

My unsatisfactory workaround is:

#ifdef _ADDFAC // Dinkumware macro
    std::locale myLoc = std::_ADDFAC(std::locale::classic(), new my_codecvt);
#else
    std::locale myLoc = std::locale(std::locale::classic(), new my_codecvt);
#endif

Do you have a better one?

INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

Re: VC6 problem: locale loc(locale::classic(), new myfac)

Stuart Dootson9-Jul-09 22:01

How to hide Standard Toolbar button in IE

9-Jul-09 22:01

I'm sure this is teaching grandma to suck eggs, but the only thing I'd suggest is to encapsulate that in another function, so you only need to do it once, i.e:

template<class Facet>
std::locale AddFacet(std::locale const& l, const Facet* f)
{
#ifdef _ADDFAC // Dinkumware macro
    return std::_ADDFAC(std::locale::classic(), new my_codecvt);
#else
    return std::locale(std::locale::classic(), new my_codecvt);
#endif
}

Alternatively, use this:

#ifndef _ADDFAC // Dinkumware macro
#define _ADDFAC (std::locale)
#endif

and use _ADDFAC for all platforms.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

am 20098-Jul-09 22:40

am 2009

8-Jul-09 22:40

Hello,

I want to hide standard toolbar button of IE. i can hide IE std .toolbar , but affetcs my othere toolbar also. So is there any way to hide only Standard Toolbar button of IE.

thanks
Am

32bit client talking to a 64bit local server

Kannan Ramanathan4-Jul-09 3:58

4-Jul-09 3:58

Is it possible to have a 32bit client initialize/invoke methods in a 64bit local COM server? If yes, how do I set up the Proxy/stub DLLs? The target OS I have in mind is Vista64 or Win7-64 (so the 32bit client will be running from with in WOW64).

Also, can I go ahead with ATL 8 for implementing the above scenario? Any examples available online? Thanks.

Kannan Ramanathan4-Jul-09 4:00

4-Jul-09 4:00

One more req I have to worry abt: The 64bit local server should be able to implement connection points (32bit client being the sink)...is this possible? Thanks.

Stuart Dootson4-Jul-09 4:50

4-Jul-09 4:50

This thread[^] documents the opposite scenario (64-bit client, 32-bit server) - does that enlighten the situation at all?

And this thread[^] indicates that 32-bit client and 64-bit client should be OK.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan4-Jul-09 5:32

4-Jul-09 5:32

Thanks Stuart for the pointers. Looks like all I need to do is to build/register both 32bit and 64bit proxy/stubs. Is that right?

In this case, can I also make the 32bit code act as a sink? Thanks.

Stuart Dootson4-Jul-09 5:35

4-Jul-09 5:35

Ummmm - yes, no, maybe - I really don't know Blush | :O

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Kannan Ramanathan4-Jul-09 7:25

4-Jul-09 7:25

I did a quick check using ATLDUCK sample. Built the atlduck (local com server) in to 64bit, tried connecting to it from duck (32bit). CoCreateInstance worked perfectly, but when duck tried an Advise() to atlduck, it crashed with an error msg "runtime terminated the app" Sigh | :sigh:

... trying out some more experiments, will update on the results.

Kannan Ramanathan5-Jul-09 3:13