Author |
Topic: A solution to the old FN_setproc problem. (Read 604 times) |
|
sveinioslo
Developer
member is offline
Posts: 64
|
 |
Re: A solution to the old FN_setproc problem.
« Reply #10 on: Aug 18th, 2014, 11:56pm » |
|
Hmm !?
Just to be clear if this is a windows problem or not.
Are you saying that you ran this code on a windows 8 machine, and it just ended. you didn't see a slowly pulsating window ??
Code:SWP_NOMOVE = 2
SWP_NOZORDER = 4
WM_SIZE = 5
INSTALL @lib$+"eventlib"
PROC_eventinit
PROC_eventregister(WM_SIZE, PROCstuck())
SYS "SendMessage",@hwnd%,WM_SIZE,0,0
PROC_eventpoll
END
DEF PROCstuck(m%,w%,l%)
PRIVATE X% : X%+=1 : IF X%>400 X%=0
SYS "SetWindowPos", @hwnd%, 0, 0, 0, 200+X%, 200+X%, SWP_NOMOVE + SWP_NOZORDER
WAIT 1: ENDPROC
Are you also saying that on a windows 8 machine, this code will also just end ??
Code: INSTALL @lib$+"eventlib"
PROC_eventinit
PROC_eventregister(123, PROCstuck())
SYS "SendMessage",@hwnd%,123,0,0
PROC_eventpoll
END
DEF PROCstuck(m%,w%,l%)
SYS "SendMessage",@hwnd%,123,0,0
ENDPROC
If so, then yes, there is a difference between win7 and win8.
Svein
|
|
 Logged
|
|
|
|
rtr
Guest
|
|
Re: A solution to the old FN_setproc problem.
« Reply #11 on: Aug 19th, 2014, 08:42am » |
|
on Aug 18th, 2014, 11:56pm, sveinioslo wrote:| Are you saying that you ran this code on a windows 8 machine, and it just ended. you didn't see a slowly pulsating window ?? |
|
Those programs are not relevant to the issue under discussion. The first sends a SetWindowPos message every time a WM_SIZE message is received, so of course you have deliberately created a feedback mechanism. The second program sends another WM_CONTEXTMENU message every time one is received, so again you have created a feedback mechanism.
If you deliberately create feedback, you can expect unwanted things to happen. Exactly what happens will be difficult to predict, but depending on the system dynamics an oscillatory behaviour is entirely reasonable. For example simply adding delay in the feedback path can dramatically change the system dynamics (in servo-system theory this would be equivalent to changing the phase of the feedback signal).
You may end up with a system which exhibits damped oscillation, which eventually dies down, or a system which exhibits oscillation which builds up until it is limited by a non-linearity. Often the optimum solution is considered to be 'critical damping', which is a non-oscillatory transition to a new steady-state. The mathematics of such systems is well understood, and as an electronics engineer I have plenty of experience of them!
If you are interested in understanding more about servo theory and how to control a system's dynamics, there is plenty of information available online such as:
http://en.wikipedia.org/wiki/Damping
But none of this has any relevance to SCROLL.BBC, which is the program you were reporting problems with. SCROLL.BBC does not contain such a feedback mechanism. When a WM_SIZE message is received, another WM_SIZE message is generated only very rarely - specifically when the SetScrollInfo causes a scrollbar to appear or to disappear. I would not expect SCROLL.BBC to exhibit oscillatory behaviour, and I see no trace of it doing so here.
Richard.
|
|
Logged
|
|
|
|
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
|
|
|
|
|
