[This topic is a spin off from elsewhere]

In article <mpro.rafg4d01cbkc603j7.news@stevefryatt.org.uk>,
Steve Fryatt <news@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <mpro.rafl8502cchs903j7.news@stevefryatt.org.uk>,
Steve Fryatt <news@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16 Apr, Paul Sprangers wrote in message
<59da004dcaPaul@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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <59da0a93c2Paul@sprie.nl>,
Paul Sprangers <Paul@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <59d9b91b68News03@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <845f0dda59.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

I think what Martin Avison was saying in message <59d9b91b68News03@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)