Re: WinSock SendData -> unknown Exception
On Feb 18, 6:50 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
I would not use a timeSetEvent callback to handle socket communication. =
Because there
should be no serious time constraints for TCP/IP or UDP communication, I w=
ouldn't use
anything more sophisticated than a SetTimer() call.
Note that you *can* use a socket in a separate thread (see my essay on mul=
tithreaded
sockets), but it involves giving complete control of the socket to the thr=
ead, and never
again using the socket from any other thread, including the thread that cr=
eated it.
=
joe
On Mon, 18 Feb 2008 07:52:23 -0800 (PST), clinisbut <clinis...@gmail.com> =
wrote:
On Feb 18, 4:31 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
It turns out that the timeSetEvent documentation does not say that the =
callback occurs in
a separate thread. This is a documentation failure, because the call=
back really is called
joe
On Mon, 18 Feb 2008 04:08:00 -0800 (PST), clinisbut <clinis...@gmail.co=
m> wrote:
On Feb 16, 2:00 am, Joseph M. Newcomer <newco...@flounder.com> wrote=
:
I question the fundamental decision to use an ActiveX control to do =
something as simple as
socket handling. I believe the control does synchronous I/O.
Yeah, sure! but does another issue...
Could you report ALL the values of the COleDispatchException object? =
Most especially the
m_wCode.
m_wCode = 0
I think that's the only value I've left behind.
I'm having another trouble and is happening when I call the same
function from a multimedia timer. But this time I'm getting a "First
chance exception in XXX.exe (MSWINSCK.OCX): 0xC0000005: Access
Violation".
I think it has to do with the variant type. Debugging this last error,=
I found that program crashes in function (called automatically from
mWinsock.sendData):
void COleDispatchDriver::InvokeHelperV(DISPID dwDispID, WORD
wFlags, VARTYPE vtRet, void* pvRet, const BYTE* pbParamInfo, v=
a_list
argList)
{
//BLABLABLABLA
SCODE sc = m_lpDispatch->Invoke(dwDispID, II=
D_NULL, 0, wFlags,
&dispparams, pvarResult, &excepInfo, &nArgErr); //<---This is where
error occours!!!
}
Maybe has something to do with MMTimer? this is how I implement it:
void CALLBACK CUart3Dlg::StartTimer( UINT wTimerID, UINT msg, DWORD
dwUser, DWORD dw1, DWORD dw2 )
{
CUart3Dlg* obj = (CUart3Dlg*) dwUser;
obj->Timer_SendData( wTimerID );
}
void CUart3Dlg::Timer_SendData( UINT wTimerID )
{
if( buffer_out.size() > 0 )
{
if( ui_retry_counter<MAX_RETRY_COUNT )
{
//Some operations
}
else
{
std::vector<unsigned char=
out_tcp;
//fead out_tcp with data
//...........
Send_TCP( out_tcp ); <--Th=
is calls my m_Winsock.sendData( v );
}
}
}
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
So will have similar problems using CAsynsocket?? What you suggest
then to work with sockets?
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
I don't use MMTimer to manage socket communication, but serial comm.
Every X ms I'm sending a frame through serial, and if a specific
condition is true before that sending, I send a socket to a client
informing that "problem". That's 'cause I use MMTimer, to control
frame sending to serial comm.
Maybe when this condition is true could I send a message to main GUI
thread to send that socket?