🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.nativeapi
Article #431

Re: WM_TIMER / WM_PAINT

#431
From: Bob Gonder
Date: Sun, 13 Apr 2008 00:01
72 lines
3236 bytes
UO wrote:


>After creating the window, because the code in "case WM_TIMER:" takes more 
>time than the poll time of the timer,

Then you need to increase the timer amount.

> do WM_TIMER messages fill the message queue buffer in the end?

I think so.
Another thing to try is to show the elapsed time between WM_TIMER.
Vary the code so it stalls for a while,
then bypasses to zip through any backlog.
Take note of the time, especially if it is less than the Timer amount.

> I've noticed, the line marked with "A" never executes, that means g_cnt is never greater 
>than one.

They run sequentially, so the counter never varies.

>    case WM_TIMER:
>        g_cnt++;
>            sprintf(buf, "g_cnt=%d", g_cnt);
>            MessageBox(hwnd, buf, "info", MB_OK); //B
>        g_cnt--;
>    break;
>
>What is the difference between Code //1 and Code //2 ?

Well, Code 2 calls MessageBox every time while Code 1 never does.
Seems obvious that MessageBox is processing messages.
As a further test, add another counter and display it on your Form.

        g_cnt++;
        g_cnt2++;
            sprintf(buf, "g_cnt=%d  g_cnt2=%d", g_cnt, g_cnt2);
		Form1->Label1.SetTextBuf( buf );
        g_cnt--;

Win32API alternative to VCL SetTextBuffer is
	SendDlgItemMessage( hwnd, nIDDlgItem, WM_SETTEXT, 0, (LPARAM)buf );
 
You should see cnt2 increase while cnt1 remains 1.

>I've never noticed that "case WM_TIMER:" and "case WM_PAINT:" are executed
>simultanously. Is it always true in this case?

Yes.
Messages all happen sequentially in the main thread.
This isn't an interrupt system.
The thread that owns the window executes each message in the queue.

What you were seeing with MessageBox was the main thread
processing WM_TIMER, then running/processing MessageBox,
processing WM_TIMER within that window, then recursing on
down until the stack or resources run out.

The way you get around that is to guard the code:
>    case WM_TIMER:
	if( 0 == g_cnt )
	{
	    ++g_cnt;
            sprintf(buf, "g_cnt=%d", g_cnt);
            MessageBox(hwnd, buf, "info", MB_OK); //B
	    --g_cnt;
	};
>    break;


Multithreaded apps however, can be working on different
messages, just not for the same form instance.
Technical Details
Message-ID: <2rg204ln4b2t3hulvbbg5k3jq79ql01ioh@4ax.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail
References: <48007897$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 10cc67,23aafd5476c6b2a9
X-Google-Attributes: gid10cc67,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
From: Bob Gonder <notbg@notmindspring.invalid>
Newsgroups: borland.public.cppbuilder.nativeapi
Subject: Re: WM_TIMER / WM_PAINT
Date: Sat, 12 Apr 2008 17:01:11 -0700
Organization: MindSpring Enterprises, Inc.
Reply-To: notbg@notmindspring.invalid
Message-ID: <2rg204ln4b2t3hulvbbg5k3jq79ql01ioh@4ax.com>
References: <48007897$1@newsgroups.borland.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 67.77.144.72
X-Trace: newsgroups.borland.com 1208044866 67.77.144.72 (12 Apr 2008 17:01:06 -0700)
Lines: 74
Path: arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail