MultiWin and *Refresh

Discussions related to mouse, keyboard and Graphical User Interface
Post Reply
KenDown
Posts: 33
Joined: Wed 04 Apr 2018, 06:36

MultiWin and *Refresh

Post by KenDown » Thu 26 Apr 2018, 17:44

I can see why *Refresh is disabled when using MultiWin - if it was enabled and *REFRESH OFF issued, *all* the windows would only refresh when one of them was manually refreshed. However I have a program where that would be quite acceptable - for a short period of time I need to control the refreshing while a graphics routine in the main window operates, and it doesn't matter what happens in the other windows. Once the routine has finished I can switch *REFRESH ON and be back to normal.

Is there anyway of enabling *Refresh?

guest
Posts: 107
Joined: Mon 02 Apr 2018, 09:12

Re: MultiWin and *Refresh

Post by guest » Thu 26 Apr 2018, 17:59

KenDown wrote:
Thu 26 Apr 2018, 17:44
Is there anyway of enabling *Refresh?
You don't say whether you are asking about BB4W or BBCSDL. I think I'm right in saying that in the latter case the child windows don't automatically refresh anyway, so if you want to suppress the refresh you need only stop calling PROC_selectwin() on that window. in BB4W the refresh is handled asynchronously by Windows, but you might find that calling LockWindowUpdate will work. Failing that you'd probably have to create a custom version of MULTIWIN.BBC with that capability added.

Richard.

KenDown
Posts: 33
Joined: Wed 04 Apr 2018, 06:36

Re: MultiWin and *Refresh

Post by KenDown » Wed 02 May 2018, 06:17

Hmmmm. Thanks. (It's BB4W, by the way.)

The LockWindow certainly locks the window, but unlike REFRESH, which refreshes whenever it is called, LockWindow appears to only refresh at the end of the procedure, so instead of getting my text scrolling smoothly, it suddenly appears at the final position.

Thanks anyway.

KenDown
Posts: 33
Joined: Wed 04 Apr 2018, 06:36

Re: MultiWin and *Refresh

Post by KenDown » Mon 17 Sep 2018, 01:56

For anyone else who may be having a similar problem, I think I have cracked it! The solution is to use SYS"SendMessage" WM_SETREDRAW (which has the value of &B) This is a snippet from my program which will, I hope, show how it is done.

REM width% width of screen: fx% width of string a$
sclx%=leftx%+width%
SYS"SendMessage",hw2%,&B,FALSE,0
REPEAT
IFshadow%GCOL0,0:MOVEsclx%+offset%,texty%-offset%:PRINTa$
GCOL0,col%:MOVEsclx%,texty%:PRINTa$
SYS"SendMessage",hw2%,&B,TRUE,0
SYS"RedrawWindow",hw2%,0,0,&401
g%=INKEY(1)
SYS"SendMessage",hw2%,&B,FALSE,0
sclx%-=scrspd%:OSCLI("DISPLAY "+CHR$34+@dir$+"temp.bmp"+CHR$34+" 0,"+STR$(texty%-fy%))
UNTILsclx%<leftx%-fx%ORg%>0
SYS"SendMessage",hw2%,&B,TRUE,0

Setting the parameter to FALSE is the equivalent of *REFRESH OFF whereas setting it to TRUE is the equivalent of both *REFRESH and *REFRESH ON

I do not know the reason why, but if the delay is less than 1 centisecond (ie. INKEY(0) or no INKEY at all) the text jumps across the screen, whereas with INKEY(1) the text scrolls smoothly. The same thing happens if you put the INKEY after the message.

Post Reply