1. Stack limits query - windows dlls
I have recently stopped a problem which went along the following
lines:
windows (or win32lib) calls onpaint(1) -- some lengthy graphics stuff
onpaint calls doEvents
doEvents calls onkeydown
onkeydown calls onpaint(2) -- user has zoomed
...
onpaint(3)
...
onpaint(4)
...
of course, onpaint(1)..(3) will check whether to continue and just
return, without doing any more graphics stuff, but only after doEvents
returns. So if the user (me) zooms and zooms and zooms, before (any
of) the graphics drawing gets finished, the stack just grows and grows
until it goes bang.
The Euphoria interpreter does not have this problem running pure Eu
code - I've just tested it to over 1,000,000 recursive calls and it
just gets a bit slower, but the windows dlls I think have a much
smaller limit, (128K?) and crash.
I made onkeydown count how many outstanding calls it had made to
onpaint and ignore any further attempts to zoom when it reached a
certain number, until that is, they had finished & it is safe to
resume. Stopped the problem quite definitely anyway
(invalid page fault in module KERNEL32.DLL at 015f:bff71459)
So after all that, my question is simple: what would a sensible limit
be?
Or instead, should I be detecting that onpaint is still running, so
instead of calling it, set appropriate flags, safe in the knowledge
that control will eventually return to the statement following the
doEvents call, so onpaint can loop back to the start?
Pete
2. Re: Stack limits query - windows dlls
I would have thought that doEvents inside the inPaint handler is a
dangerous thing. Is it really necessary? What events are you expecting to
happen during the onPaint processing? Anyways, I often do this sort of
thing...
integer painting painting = False
procedure onPaint_xxx(...)
if painting then
return
end if
painting = True
. . .
painting = False
end procedure
On Tue, 26 Nov 2002 01:02:53 +0000, Pete Lomax <petelomax at blueyonder.co.uk>
wrote:
>
> I have recently stopped a problem which went along the following
> lines:
>
> windows (or win32lib) calls onpaint(1) -- some lengthy graphics stuff
> onpaint calls doEvents
> doEvents calls onkeydown
> onkeydown calls onpaint(2) -- user has zoomed
> ...
> onpaint(3)
> ...
> onpaint(4)
> ...
>
> of course, onpaint(1)..(3) will check whether to continue and just
> return, without doing any more graphics stuff, but only after doEvents
> returns. So if the user (me) zooms and zooms and zooms, before (any
> of) the graphics drawing gets finished, the stack just grows and grows
> until it goes bang.
>
> The Euphoria interpreter does not have this problem running pure Eu
> code - I've just tested it to over 1,000,000 recursive calls and it
> just gets a bit slower, but the windows dlls I think have a much
> smaller limit, (128K?) and crash.
>
> I made onkeydown count how many outstanding calls it had made to
> onpaint and ignore any further attempts to zoom when it reached a
> certain number, until that is, they had finished & it is safe to
> resume. Stopped the problem quite definitely anyway
> (invalid page fault in module KERNEL32.DLL at 015f:bff71459)
>
> So after all that, my question is simple: what would a sensible limit
> be?
>
> Or instead, should I be detecting that onpaint is still running, so
> instead of calling it, set appropriate flags, safe in the knowledge
> that control will eventually return to the statement following the
> doEvents call, so onpaint can loop back to the start?
>
> Pete
>
> ==^^===============================================================
> This email was sent to: ddparnell at bigpond.com
>
>
>
--
cheers,
Derek Parnell
3. Re: Stack limits query - windows dlls
On Tue, 26 Nov 2002 12:18:21 +1100, Derek Parnell
<ddparnell at bigpond.com> wrote:
>
>I would have thought that doEvents inside the inPaint handler is a=20
>dangerous thing.
I found that out ;->
>Is it really necessary? What events are you expecting to=20
>happen during the onPaint processing?
Print preview. Especially if I'm drawing several pages on the screen,
it can take a while, so I want to allow the user to interrupt it,
especially zoom in or out.
>Anyways, I often do this sort of thing...
Heh, at least I'm not alone.
>
>integer painting painting =3D False
>procedure onPaint_xxx(...)
> if painting then
> return
>end if
>painting =3D True
>. . .
>painting =3D False
>end procedure
I currently have:
onpaint()
...
doEvents
if params changed then return
..
onkeydown()
if paintcounter < 20 then
paintcounter+=3D1
change params
onpaint()
paintcounter-=3D1
end if
I'll take your advice (that the sensible number of nested calls to
onpaint is ... zero). While it works fine for me standalone, if I put
it in an application it could easily get invoked from some event
handler already several calls deep and then break, so I shall try
changing it to:
onpaint()
do
save current param settings
main loop
doEvents
if params changed then exit main loop
end main loop
until params not changed
onkeydown()
change params
if not paintinprogress then
paintinprogress=3DTrue
onpaint
paintinprogress=3DFalse
end if
and see what happens.
Thanks,
Pete
