Author |
Topic: A solution to the old FN_setproc problem. (Read 605 times) |
|
sveinioslo
Developer
member is offline
Posts: 64
|
 |
Re: A solution to the old FN_setproc problem.
« Reply #12 on: Aug 19th, 2014, 11:56am » |
|
Quote:| Those programs are not relevant to the issue under discussion |
|
They were made specifically to pinpoint IF there is a feedback mechanism, and WHERE it occurs. That is: 'can it be the combination of PROCmove and PROC_eventpoll ?'
The answer is a definite yes.
Quote:| If you are interested in understanding more about servo theory |
|
We are on the same page here. I worked as an electronics system designer/programmer in the eighties.
Not been working with anything remotely close, ever since.
Quote:| SCROLL.BBC does not contain such a feedback mechanism. |
|
No, not in it self, but in combination with eventlib it does.
You may have missed that there is two consecutive "SetScrollInfo" in PROCmove.
They can both send a WM_SIZE.
So every WM_SIZE can result in 0,1 or 2 new WM_SIZE.
I am not putting any 'blame' on eventlib, this is just an unfortunate combination that can result in oscillation.
The solution is clear:
Keep canvas larger than the screen and find another way of dealing with the window resizing
And/or
Use asynchronous interrupt with a busy flag.
I have made a new video for you, which will provide 'beyond shadow of a doubt' proof.
http://fix24.net/bb4w/New_Scroll.bbc.mp4
It is for sure the WM_SIZE message.
Svein
|
|
 Logged
|
|
|
|
rtr
Guest
|
|
Re: A solution to the old FN_setproc problem.
« Reply #13 on: Aug 19th, 2014, 1:22pm » |
|
on Aug 19th, 2014, 11:56am, sveinioslo wrote:| That is: 'can it be the combination of PROCmove and PROC_eventpoll ?' The answer is a definite yes. |
|
No. If you create feedback, you can end up with an oscillatory system. That's it. It is irrelevant and unhelpful to refer to specific elements of the system such as PROCmove and PROC_eventpoll. They are no more 'responsible' for the oscillation than, for example, a single resistor or capacitor can be said to be 'responsible' for the oscillation of a hardware circuit.
It is the system as a whole which oscillates. Change any single element within that system and it is likely to change the behaviour.
Quote:The solution is clear:
Keep canvas larger than the screen and find another way of dealing with the window resizing And/or Use asynchronous interrupt with a busy flag. |
|
As far as SCROLL.BBC is concerned there is no requirement for a "solution" because there isn't a problem!
Your videos purport to demonstrate a failure mode, but even if that is the case (and I cannot reproduce it here, however hard I try) it happens only over a very narrow range of conditions and it is of trivial significance.
I WILL NOT REPLY TO ANY FURTHER COMMENTS YOU MAY MAKE.
Richard.
|
|
Logged
|
|
|
|
sveinioslo
Developer
member is offline
Posts: 64
|
|
Re: A solution to the old FN_setproc problem.
« Reply #14 on: Aug 19th, 2014, 2:18pm » |
|
Let's agree to disagree then. 
Have a good day.
Svein
|
|
Logged
|
|
|
|
Malvern
Guest
|
|
Re: A solution to the old FN_setproc problem.
« Reply #15 on: Aug 19th, 2014, 11:24pm » |
|
Just so that you know you are not the only one to see the effect I have made it do it, but it was very difficult to make happen. Win 7 64bit.
I am not going to speculate as to what causes it....
I typically don't use Eventlib but use the methods here
https://groups.yahoo.com/neo/groups/bb4w/files/%22Temp%20Folder%22/Event_Programming/
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.
|
| « Last Edit: Aug 20th, 2014, 05:28am by Malvern » |
Logged
|
|
|
|
sveinioslo
Developer
member is offline
Posts: 64
|
|
Re: A solution to the old FN_setproc problem.
« Reply #17 on: Aug 20th, 2014, 09:29am » |
|
Thank you !
Svein
|
|
Logged
|
|
|
|
Malcolm
Guest
|
|
Re: A solution to the old FN_setproc problem.
« Reply #18 on: Sep 15th, 2014, 6:27pm » |
|
on Aug 20th, 2014, 04:50am, Malvern wrote: 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?
Malcolm
|
|
Logged
|
|
|
|
|
