Wimp_RedrawWindow protocols

[Paul Sprangers]

[This topic is a spin off from elsewhere]

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

[Steve Fryatt]

On 16 Apr, Paul Sprangers wrote in message

Post by Paul Sprangers
The details that I get from Wimp_GetWindowInfo is the x and y origins of
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.

[Paul Sprangers]

Post by Steve Fryatt
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

[Harriet Bazley]

On 16 Apr 2022 as I do recall,

Post by Paul Sprangers
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]

Post by Paul Sprangers
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
<***@avisoft.f9.co.uk> was that Wimp_RedrawWindow should
not be called by your program *at all* save in response to a Wimp_Poll

Post by Paul Sprangers

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

[Paul Sprangers]

Post by Harriet Bazley
I think what Martin Avison was saying in message
not be called by your program *at all* save in response to a Wimp_Poll

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.

Post by Harriet Bazley
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.

Post by Harriet Bazley

Post by Paul Sprangers
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

[Martin]

Post by Paul Sprangers
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.