BBC BASIC for Windows
« A solution to the old FN_setproc problem. »
Welcome Guest. Please Login or Register. Apr 5th, 2018, 9:57pm
ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018. Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.
If you require a dump of the post on your message board, please come to the support board and request it.
I expect it would show the same issues though as it uses a similar queue.
Logged
Malvern Guest
Re: A solution to the old FN_setproc problem.
« Reply #16 on: Aug 20th, 2014, 04:50am »
Quote:
It is for sure the WM_SIZE message
Yes, certainly that is what I see also. You can single step through the program when this condition arises. The handler for the WM_SIZE event is generating a further WM_SIZE event as it is being handled so the event queue never gets cleared and the oscillation is the effects of some Windows weirdness and the WHILE loop in PROC_eventpoll that never gets its exit condition met. Why Windows doesn't behave as RTR predicted under all circumstances is for Microsoft to know.
The handler for the WM_SIZE event is generating a further WM_SIZE event as it is being handled...
If this is the case couldn't you just put an "ON MOVE LOCAL : RETURN" in the part that deals with WM_SIZE so that the next ON MOVE event(s) that occur within the PROCmove would get ignored?