Interesting Behaviour

[John_N_2]

Dear Paul:

I have had three tear your hair out and stamp on it enjoyable days gettting Textwin to run. I now have it so that it scrolls and prints. It has been great fun understanding the logic in the program, but I can not say I am fully conversant with it.

I have two interesting kludges to make it work, and I do not understand either kludge, it is just that I found that it made the program work. The fascinating kludge is shown in the following code:

[cpp]DO
	        IF (busy) CYCLE ! wait for last line to finish printing
	        n2 = MIN0(n1 + 59, n3)
	        tracestring = message_string(n1:n2)
	        nc_trace = n2 - n1 + 1
	        rval = MessageBox(NULL, message_string,"Next Sring ?"C, MB_OK )
	        iret = SendMessage (hwText, WM_PAINT, 0, 0)
	        n1 = n2 + 1
		    IF (n1 >= n3) EXIT
		END DO
		    [/cpp]

If I take out the message box it does not work, specifically the call to the send message simply does not execute on the second go round, it intializes, but then nothing. I have single stepped through many times and watched all the variables, it just misses the call.

The message box does nothing for the program, it merely halts the program long enough for me to click ok, but it does nothing else. but then sendmessage works.

So my question in general is why does this work and what am I missing?

I have another question that will be on a direct email as it is of no interest to anyone except me.

Finally, if I have to call the RGB macro, how to I declare the type? - Lawrence is no help there even though he uses the macro.

Regards

JMN

[anthonyrichards]

Quoting - MacNeacail

Dear Paul:

I have had three tear your hair out and stamp on it enjoyable days gettting Textwin to run. I now have it so that it scrolls and prints. It has been great fun understanding the logic in the program, but I can not say I am fully conversant with it.

I have two interesting kludges to make it work, and I do not understand either kludge, it is just that I found that it made the program work. The fascinating kludge is shown in the following code:

[cpp]DO
	        IF (busy) CYCLE ! wait for last line to finish printing
	        n2 = MIN0(n1 + 59, n3)
	        tracestring = message_string(n1:n2)
	        nc_trace = n2 - n1 + 1
	        rval = MessageBox(NULL, message_string,"Next Sring ?"C, MB_OK )
	        iret = SendMessage (hwText, WM_PAINT, 0, 0)
	        n1 = n2 + 1
		    IF (n1 >= n3) EXIT
		END DO
		    [/cpp]

If I take out the message box it does not work, specifically the call to the send message simply does not execute on the second go round, it intializes, but then nothing. I have single stepped through many times and watched all the variables, it just misses the call.

The message box does nothing for the program, it merely halts the program long enough for me to click ok, but it does nothing else. but then sendmessage works.

So my question in general is why does this work and what am I missing?

I have another question that will be on a direct email as it is of no interest to anyone except me.

Finally, if I have to call the RGB macro, how to I declare the type? - Lawrence is no help there even though he uses the macro.

Regards

JMN

How are you monitoring the Sending/receipt of each WM_PAINT message? It might be worth looking at the WM_PAINT Help entry, as it contains stuff like
"The system sends an internal WM_PAINT message only once. After an internal WM_PAINT message is returned from GetMessage or PeekMessage or is sent to a window by UpdateWindow, the system does not post or send further WM_PAINT messages until the window is invalidated or until RedrawWindow is called again with the RDW_INTERNALPAINT flag set. " (my underline)

If you display a message box and it appears on top of your window, then when it is closed the system will send its own WM_PAINT messsage to get the area obscured bythe messagebox windowredrawn.

[John_N_2]

Quoting - anthonyrichards

How are you monitoring the Sending/receipt of each WM_PAINT message? It might be worth looking at the WM_PAINT Help entry, as it contains stuff like
"The system sends an internal WM_PAINT message only once. After an internal WM_PAINT message is returned from GetMessage or PeekMessage or is sent to a window by UpdateWindow, the system does not post or send further WM_PAINT messages until the window is invalidated or until RedrawWindow is called again with the RDW_INTERNALPAINT flag set. " (my underline)

If you display a message box and it appears on top of your window, then when it is closed the system will send its own WM_PAINT messsage to get the area obscured bythe messagebox windowredrawn.

Dear Anthony:

Thank you for your response. I need to learn about the message queue and how to watch it. Windows does some interesting things that I do not fully understand, but it is a lot of fun learning. Like a lot of programming the fun is in the challenge not the end.

I read the stuff on WM_Paint, and I need to start playing with this stuff to understand this two way communication. it is really not significantly different to a LISP program with several recursive subroutines that are interlinked.

Paul wrote a nice program and it has been fun playing with it, although I have consumed two cases of beer over the two months I have played with it, which is a record for my consumption. My wife has been complaining that I have disappeared into fairy land again, whenever I start playing with the program.

JMN

[Paul_Curtis]

Quoting - MacNeacail

Dear Anthony:

Thank you for your response. I need to learn about the message queue and how to watch it. Windows does some interesting things that I do not fully understand, but it is a lot of fun learning. Like a lot of programming the fun is in the challenge not the end.

I read the stuff on WM_Paint, and I need to start playing with this stuff to understand this two way communication. it is really not significantly different to a LISP program with several recursive subroutines that are interlinked.

Paul wrote a nice program and it has been fun playing with it, although I have consumed two cases of beer over the two months I have played with it, which is a record for my consumption. My wife has been complaining that I have disappeared into fairy land again, whenever I start playing with the program.

JMN

Well, this is clearly a three-case problem. You cannot use MessageBox as a diagnostic for this sort of issue, since it inserts literally thousands of WM_ messages in the queue, completely obscuring whatever is going on with the program's real messages. What is the return from SendMessage and its GetLastError status? Is the WM_PAINT not getting sent, or not getting received? There is no recursion going on here: there is only one thread, and the BUSY flag was put in specifically to block the program sending a(nother) WM_PAINT to textproc while textproc is rendering text from a previous message. Note that the setting and clearing of the BUSY flag occur in the WM_PAINT message-processing code, and the flag will be modified whether the PAINT message was originated by this program or some other windows-generated event (such as a MessageBox on top of the text window).