Wimp_RedrawWindow protocols

[Paul Sprangers]

[This topic is a spin off from elsewhere]

In article <mpro.rafg4d01...@stevefryatt.org.uk>,
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> > > When a Wimp_Poll returns reason code 1 (RedrawWindow), then
> > > Wimp_RedrawWindow must be the first Wimp call made, and it should
> > > not be called at any other time.

> > Ah, now I understand what you mean - and I sin against that rule
> > indeed. Before calling Wimp_RedrawWindow, I do a Wimp_GetWindowInfo
> > call. Should I really move that one after the redraw call?

> What details do you need to find from Wimp_GetWindowInfo to perform the
> redraw, that you don't get in the block returned by Wimp_RedrawWindow and
> Wimp_GetRectangle?

> > If I do, things go horribly wrong.

> Define "horribly wrong"... which might help us help you. :-)

Horribly wrong in this case means that I get a 'Number too big' error in
another subroutine when opening the application window.

The details that I get from Wimp_GetWindowInfo is the x and y origins of
the window in question:

SYS "Wimp_GetWindowInfo",,block%
ox% = block%!4 - block%!20
oy% = block%!16 - block%!24

However, I noticed that I can move the latter two lines to within the WHILE
more% - ENDWHILE loop and delete the Wimp_GetWindowInfo call, so that the
RedrawWindow call is the first one in the redraw routine. Unfortunately, it
doesn't change anything about some other glitches, that probably have
nothing to do with the redraw routine, but the more so with my general and
ubiquitous flaws.

Paul

--
http://riscos.sprie.nl

[Steve Fryatt]

On 16 Apr, Paul Sprangers wrote in message
<59da004...@sprie.nl>:

> The details that I get from Wimp_GetWindowInfo is the x and y origins of
> the window in question:
>
> SYS "Wimp_GetWindowInfo",,block%
> ox% = block%!4 - block%!20
> oy% = block%!16 - block%!24

You should probably be calling

SYS "Wimp_GetWindowInfo",,block% OR 1

unless you know that you have space for all of the icon definitions in
block%, otherwise memory corruption will be a risk. With bit 0 set, the Wimp
will only return the main window data and omit the icon blocks at the end --
so you know how big the returned block will be.

Unless you need the entire window definition, which you don't above,
Wimp_GetWindowState is a better bet, too. Although often, as in this case,
the Wimp includes the information in the return from the call that you've
just made -- so there's no need for any additional call at all.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[Paul Sprangers]

In article <mpro.rafl8502...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> You should probably be calling

> SYS "Wimp_GetWindowInfo",,block% OR 1

> unless you know that you have space for all of the icon definitions in
> block%

The window in question doesn't have any icons at all, but the point was
that I shouldn't call Wimp_GetWindowInfo in the first place. At least, not
before calling Wimp_RedrawWindow.

The start of the redraw routine was originally:

DEF PROCredraw(wh%)
!block% = wh%

SYS "Wimp_GetWindowInfo",,block%
ox% = block%!4 - block%!20
oy% = block%!16 - block%!24

SYS "Wimp_RedrawWindow",,block% TO more%
WHILE more%
etc...

Following Martin A.'s suggestion, I now have:

DEF PROCredraw(wh%)
!block% = wh%
SYS "Wimp_RedrawWindow",,block% TO more%
WHILE more%

ox% = block%!4 - block%!20
oy% = block%!16 - block%!24

etc...

There's no noticeable difference in behaviour between the two versions,
although I would think that the first one might be a microscopic bit
faster, since it has to calculate the ox% and oy% only once.

So, actually my question is: how compulsory is the alledged rule that no
other call should precede the Wimp_RedrawWindow call?

Paul

--
http://riscos.sprie.nl

[Harriet Bazley]

On 16 Apr 2022 as I do recall,

Paul Sprangers wrote:

> The window in question doesn't have any icons at all, but the point was
> that I shouldn't call Wimp_GetWindowInfo in the first place. At least, not
> before calling Wimp_RedrawWindow.

[snip]

> So, actually my question is: how compulsory is the alledged rule that no
> other call should precede the Wimp_RedrawWindow call?
>

I think what Martin Avison was saying in message
<59d9b91b...@avisoft.f9.co.uk> was that Wimp_RedrawWindow should
not be called by your program *at all* save in response to a Wimp_Poll
redraw window request (reason code 1):

> > When a Wimp_Poll returns reason code 1 (RedrawWindow), then
> > Wimp_RedrawWindow must be the first Wimp call made, and it should not
> > be called at any other time.
> >

> > Does that help?

Looking through the StrongHelp manuals (I've never done any window
updating outside the poll loop), I think you may be intended to call
Wimp_ForceRedraw (which will cause your window to receive the above
mentioned Wimp_Poll request) or Wimp_UpdateWindow, which does the same
thing, only not via the poll loop but immediately.

https://www.riscosopen.org/wiki/documentation/show/Wimp_UpdateWindow

--
Harriet Bazley == Loyaulte me lie ==

You /really/ don't want to know.

[Martin]

In article <59da0a9...@sprie.nl>,

Paul Sprangers <Pa...@sprie.nl> wrote:
> Following Martin A.'s suggestion, I now have:

> DEF PROCredraw(wh%)
> !block% = wh%
> SYS "Wimp_RedrawWindow",,block% TO more%
> WHILE more%
> ox% = block%!4 - block%!20
> oy% = block%!16 - block%!24
> etc...

> There's no noticeable difference in behaviour between the two
> versions, although I would think that the first one might be a
> microscopic bit faster, since it has to calculate the ox% and oy%
> only once.

If that is a concern, how about moving the ox% & oy% calculations from
within the WHILE to just before it? I do not think that the visible
area will change between redraws - although obviously the redraw
rectangle will.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

[Paul Sprangers]

In article <845f0dda5...@bazleyfamily.co.uk>,

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

> I think what Martin Avison was saying in message
> <59d9b91b...@avisoft.f9.co.uk> was that Wimp_RedrawWindow should
> not be called by your program *at all* save in response to a Wimp_Poll
> redraw window request (reason code 1):

Ah, I see. And that's what I do. Wimp_RedrawWindow occurs only once in the
entire program, as a response to reason code 1.

> Looking through the StrongHelp manuals (I've never done any window
> updating outside the poll loop), I think you may be intended to call
> Wimp_ForceRedraw (which will cause your window to receive the above
> mentioned Wimp_Poll request) or Wimp_UpdateWindow, which does the same
> thing, only not via the poll loop but immediately.

I already use the Wimp_UpdateWindow call for direct update of distinct
parts of the window. So, I think I've done this part of the redraw
protocols right.

> > DEF PROCredraw(wh%)
> > !block% = wh%
> > SYS "Wimp_RedrawWindow",,block% TO more%
> > WHILE more%
> > ox% = block%!4 - block%!20
> > oy% = block%!16 - block%!24
> > etc...

> If that is a concern, how about moving the ox% & oy% calculations from
> within the WHILE to just before it? I do not think that the visible
> area will change between redraws - although obviously the redraw
> rectangle will.

Moving those calculations to just before the WHILE works indeed, but only
after the RedrawWindow call. Moving them before that call generates an
error, unless it is preceded by the GetWindowInfo call. This may be obvious
for the better informed, but not for me. The redraw routine now looks like
this:

DEF PROCredraw(wh%)
!block% = wh%
SYS "Wimp_RedrawWindow",,block% TO more%

ox% = block%!4 - block%!20
oy% = block%!16 - block%!24

WHILE more%
etc...

To me those calculations between the call and WHILE look a bit silly, but
well... it works, and I no longer need the GetWindowInfo call.

Many thanks for your thoughts!

Paul

--
http://riscos.sprie.nl