ON_WM_TIMER()より高速なメッセージ

[Gammodler1]

Visual Studio6です。
ON_WM_TIMERより高速なEventはないのでしょうか？

コード:

BEGIN_MESSAGE_MAP(CIlcMMIView, CFormView)
	//{{AFX_MSG_MAP(CIlcMMIView)
		ON_WM_CTLCOLOR()
		ON_WM_TIMER()
	//}}AFX_MSG_MAP
	 ON_MESSAGE(WM_USER_RCVSTS, OnRcvSts)
END_MESSAGE_MAP()

[Gammodler1]

済みません。途中で投稿になってしまいました。
受信専用スレッドで受けたデータを
::PostMessage(pView->hWnd, WM_USER_RCVSTS, (WPARAM)buf, 0);

でpViewスレッドに送付、OnRcvSts()を利用しているのですがUpdateに非常に時間がかかっています。1sec弱の感じです。
これを一桁以上高速にするON_WM_TIMER()に代わるメッセージ、Eventはないのでしょうか？。

舌足らずかもしれませんがよろしくお願いいたします。

[へにっくす]

その前にOnRcvSts()関数で1secかかっている、ということはありませんか？
一応念のため。GetTickCount関数を使って、時間を測定してみてください。
あるいはソースを掲示すると、識者から何か教えてくれるかもしれません。

これを一桁以上高速にするON_WM_TIMER()に代わるメッセージ、Eventはないのでしょうか？。

そんなものない
とゆーか、連続でやりたいなら繰り返しSendMessageすればいい。
PostMessageはメッセージキューに送って、あとはOSに任せるやり方だから、思い通りにはいかんでしょ
プロセスかスレッドの優先度を高くするくらいしか…

[みけCAT]

求めているのはこれでしょうか？
http://www.every-little.com/tips/active ... imer.xhtml

timeSetEvent関数
http://msdn.microsoft.com/ja-jp/library/cc428796.aspx
timeKillEvent関数
http://msdn.microsoft.com/ja-jp/library/dd757630.aspx

[softya（ソフト屋)]

MFCだと思いますがメッセージを処理して貰うのは別のメッセージ処理が終わってからですので、へにっくすさんの言われる通りOnRcvSts()関数が長かったら何も出来ないと思います。その場合は、OnRcvSts()関数の処理時間が長い事自体問題なので、そこはスレッドに変えてもらうなどの処置が必要でしょう。
専有さえなければWM_TIMERなら100ms周期ぐらいでなら揺らぎがあるとは思いますが十分に可能だと思います。

[Gammodler1]

へにっくす様　みけCAT様　softya様
Resありがとうございました。
OnRcvSts()の実行時間はGetTickCount関数で測定できていないのですが、負荷の重さは当然、この問題に影響します。内容としてはEdit　Box　８桁X15個、ボタンのONOFF表示5個など多少高負荷ではありますが、これらを次々に外して行ってみたのですが結果にはほとんど影響がみられません。
以前ほぼ同じ内容でスレッドを用いず、OnTimerで実行していた時は十分高速に表示できていました。ただsetTimer、killTimerを随所に入れなければならないので使い勝手が悪く、なんとか受信専用スレッド方式で行きたいと思っています。

postMessageをsendMessageに変更もしてみたのですが不調でした。
なおこの信号源はLinuxマシンでソケット経由で受信しています。
受信スレッド：

コード:

static UINT doBeginMonitorDevThread( LPVOID pParam )   //  スレッド制御関数
{
	int nBytesRecv;
	char buf[STSSENDSIZE];
	while(monitorDev_FlagExitThread == TRUE){
		nBytesRecv = recv(socket, buf, sizeof(buf), 0);	// Client機能で受信
		if(nBytesRecv == SOCKET_ERROR){
			monitorDev_FlagExitThread = FALSE;
			break;
		}
		// 文字列のままメインスレッドへ
		::PostMessage(pView->hWnd, WM_USER_RCVSTS, (WPARAM)buf, 0);
	}
	return 0;
}

PostMeesageをsendMeesageに変更してみたのですが、相手先のLinuxが暴走するなどの弊害がありました。

コード:

LRESULT ::OnRcvSts(WPARAM wParam, LPARAM lParam)
{
	int i;
	char reg2Str[1 2][REGL];
	char *stsStr = (char *)wParam;
	char stsStrBuf[REGL + 1];
	unsigned long reg2[20];
	stsStrBuf[REGL] = '\0';

	// 文字列に分割して受信。数値に変換
	for (i = 0; i < 1 2; i++){		
		memcpy(reg2Str[i], stsStr + REGL * i ,REGL);
		strcpy(stsStrBuf, reg2Str[i]);
		stsStrBuf[REGL] = '\0';					
		reg2[i] = strtoul(stsStrBuf, NULL, 16);	// 数値化する 
	}
	
	dispFirmStatus(reg2Str, reg2);	// EditBox, Button　 外しても効果なし
	ptRead = strtoul(reg2Str[10], NULL, 16);	// 外しても効果なし
	DoEvents();			// 下記					

	return(0);
}

コード:

DWORD ::DoEvents(VOID)
{
	MSG msg;
	while( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) ){
		if ( msg.message == WM_QUIT ){
			return( msg.message );
		}
		TranslateMessage( &msg );
		DispatchMessage( &msg );
	}
	return( 0 );
}

示唆いただけることがあればお願いいたします。

[softya（ソフト屋)]

スレッドが全力でループしていた場合もメインのWM_TIMERは遅延します。
スレッドにSleep(500);とかを入れて改善するならスレッドが原因でしょう。

[Gammodler1]

softya様
どうやらON_WM_TIMER()の周期が仕様に合わないということが基本的な問題であることが分かりました。
受信スレッドは使用しますが、messageは発行しない方式でやり直すことにしました。

ありがとうございました。