Re: Timeout with RPC calls?
Quote:
Originally Posted by Marc G
Actually, after thinking about it, I don't really need a COM service like you mentioned, but a COM exe would suffice. There does not need to run exactly 1 Wallpaper Cycler on the machine. Each user has there own instance running of it, so a standard COM exe would be ok i think.
Good, that means you can run the same code all the way around. Yeah.
Quote:
Originally Posted by Marc G
I'll gonna do some reading on COM programming. Would it be easy/difficult to add support for a COM server to an existing program without too much trouble?
EDIT: The current project is using MFC btw.
As you may have read from other posts, my recommendation for rapid COM development is to use ATL. Although you *could* hand code COM support to you current code, I feel maybe the simplest way is to design your server interfaces (i.e. what data and methods the client needs to access), then build the server with ATL. The ATL wizards will create all the stub code and then you can add the interfaces and methods using another wizard. From there you can connect up the new methods to your old methods.
If you can define what the interface and methods look, I would be glad to help you create the stub server code.
Arjay
Re: Timeout with RPC calls?
I think here the challenge would be mixing ATL and MFC !!
i.e. introducing ATL into already existing MFC app..
Re: Timeout with RPC calls?
Quote:
Originally Posted by Arjay
Compare the client code above to the COM code below - COM still wins :rolleyes:
Code:
IWallpaperCyclerPtr spWPCycler( __uuidof( WallpaperCycler ) );
spWPCycler->DoWorkOrGetInfo();
True, but I just wanted to say it's not that complicated ;)
Re: Timeout with RPC calls?
Quote:
Originally Posted by kirants
I am not sure how you are loading the async calls. Is it using LoadLib/GetProcAddress.
Anyways, if you are making sure in code that the async RPC calls are protected by OS version check, you can avoid using dynamic loading, but use straight calls to the APIs. However, in your linker settings you have to specify this particular dll to be delay-loaded. Search for DELAYLOAD
Well, I first tried the LoadLibrary/GetProcAddress methods, but that didn't work because the underlying RPC mechanism somewhere used some Async functions that I could't resolve with GetProcAddress.
So, I tried your solution of delay loading and OS-version-guarding async calls. I created 2 RPC methods: GetImage and GetAsyncImage. The async one is used on Windows 2K or later.
It compiled ok. It executed perfectly on Windows 2K or later. The resulting executable did load/run on Windows 9x. BUT, once I did my first RPC method call (GetImage -> non-asynchronous!) on 9x I got the following error "Incompatible version of the RPC stub.". So I think that this solution isn't working either :(
Quote:
Originally Posted by Arjay
Good, that means you can run the same code all the way around. Yeah.
As you may have read from other posts, my recommendation for rapid COM development is to use ATL. Although you *could* hand code COM support to you current code, I feel maybe the simplest way is to design your server interfaces (i.e. what data and methods the client needs to access), then build the server with ATL. The ATL wizards will create all the stub code and then you can add the interfaces and methods using another wizard. From there you can connect up the new methods to your old methods.
If you can define what the interface and methods look, I would be glad to help you create the stub server code.
Arjay
Thank you, but like kirants said, I think it will be difficult to integrate ATL COM objects into my already existing MFC framework.
Anyway, I have now implemented a quick and a bit dirty hack ;)
I have defined the following:
Code:
#define AfxMessageBox NuonSoftWPC::ScreenSaverSafeMsgBox
And my NuonSoftWPC::ScreenSaverSafeMsgBox function won't show the messagebox when the screensaver is running. I know it's a bit dirty, but it works perfectly and currently I don't have the time to work on this problem any further. I still plan on trying to solve it properly for a future version. Perhaps using your COM suggestions.
