I have seen the other threads on this forum where the SendMessage() failure when sending commands to the Skype Client, with the invalid window handle error, was due to the programmer failing to set the WndProc to 1 before returning. I do not have that problem. In fact I even have a trap at the end of my WndProc that checks for any exits where the Result code is not 1 and the Windows Message is WM_COPYDATA. The trap is never triggered. In addition, before I made certain changes to my program, the problem only happened intermittently. Now I can't even send one command to the Skype Client without it failing. I validated the Skype Client API window handle so that doesn't seem to be the problem. Also, I am running Skype Client version 4.1.0.141 which is a version that is reported to have the bug fix related to the SendMessage() problems that earlier versions had.

Does anyone have any tips or tests I could try?

Also, did they ever recreate the "no time-out" registry key that the older Skype clients had for stopping the Skype Client from invalidating the Skype API Window handle if the attached application took too long to return a response to a WM_COPYDATA message? If so, what is the correct registry key path on Windows and Value Name (and what should I put in the Value)?

Thanks.

I built this using Visual Studio C++ 2008 Express edition, it is the entire project, does it work?

Simply enter API commands, once the program is approved, and attached to the Skype client.

See Attached

Hello TheUberOverlord,

Thank you for the code link but I have either solved or I am close to solving the problem. I am back to being able to talk to the Skype client but I'm not sure if I've killed the intermittent invalidation of the Skype Window API client handle yet. I'll know soon with further testing.

My current belief is that either, the Skype client does not like too much cross-traffic (sending it commands while it is busy sending you a flurry of messages via WM_COPYDATA), or if it's because the Skype client does not like being talked to until the API attachment phase is fully complete and it has dumped the the three introductory messages.

In my previous architecture, I dumped all incoming WM_COPYDATA messages to a queue and then posted a Windows message to myself to process the queue. This was done to get the message processing out of the context of the WM_COPYDATA message receipt to avoid being dropped by the Skype client for taking too long. But when I sent commands (strings) to Skype I sent them immediately. Now I buffer the Skype commands too. I put them into a queue and post a message to myself to process the queue. However, I do not process the commands to be sent until the queue for messages coming in from Skype is completely empty. This seems to have helped a lot.

Is there a "suggestion box" for Skype? If the feature does not exist already, I would dearly love for the Skype client to dump an error report in a known directory whenever it invalidates a Skype Window API handle with a reason code and details. That would help tremendously. The handle's integrity is so integral to the Skype API that in this one case I think it would help developer's a lot.

I'll post further on my developments, especially if I have to add code to prevent any Skype sends until the Skype API client fully initializes (that is, it posts the three introductory messages about user status, etc.). Obviously the eminent possibility of bugs in my code still exists.

Thanks,
Robert

You are very welcome, to file a bug report, please see this, item #5:

https://developer.skype.com/Support