FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DRAWING

Refresh with GWorld


This is what I want to do:
1. Get a dialog from a resource file (but don't show it).
2. Copy the area of the screen under the dialog to an offscreen gworld using the correct coordinates.
3. Show, process, and dispose of the dialog.
4. Restore the area of the screen that was under the dialog


You are proposing an interesting but narrow solution to a refresh problem, similar to what the menu manager does when a menu is pulled down.

Consider the bigger picture. At any time (more accurately, whenevever your program executes HANDLEEVENTS), the user may switch your program out, clobbering any part of any or all of your windows. When your program regains control, it should then eventually respond to the system-generated _wndRefresh dialog event, by redrawing the affected windows (or parts thereof). The closing of a dialog box that overlapped your window also generates the appropriate refresh event, which can be handled in the same way. This presupposes that the program always maintains the relevant information to allow the window contents to be recreated.

A good method to ensure that your program works in this way is _never_ to draw (or print, etc) directly to a window. Instead, when you want something drawn in a window, call INVALRECT for that window, as in the example code below, and let the refresh routines do the drawing on the next HANDLEEVENTS. This approach requires some mental readjustment, but it ensures that "real" refreshes will work with no further effort on your part.
LOCAL FN InvalWholeWindow(wndNum) ' force update of entire contents
 DIM wndOut,rect;8
 wndOut=WINDOW(_outputWnd)
 WINDOW OUTPUT wndNum
 CALL SETRECT(rect,0,0,WINDOW(_width),WINDOW(_height))
 CALL INVALRECT(rect)
 WINDOW OUTPUT wndOut
END FN
Of course there are exceptions where this method cannot work, but they are few. Certain animation techniques, using _srcXOR drawing or SCROLLRECT, may make the the current window contents impossible to recreate from data.
Robert Purves

I wasn't following this line of discussion, but perhaps I can help...

Here is how I determine the drawing coordinants before drawing directly to on-screen windows... Is that your problem?
'  First I find the window coordinants on the screen
DIM  pt as POINT
Pt.h%=0
pt.v%=0
CALL LOCALTOGLOBAL(pt)
'  The I put the values into Global Vars (only test once per frame)
gWindH%=pt.h%
gWindV%=pt.v%

'  Then far away in the drawing part of the program
'  I'm finding the Source and Destination Pixmap addresses
destPixmap&=FN GETGWORLDPIXMAP(destPort&)
srcPixmap&=FN GETGWORLDPIXMAP(srcPort&)
locked% = FN LOCKPIXELS(destPixmap&)
locked2% = FN LOCKPIXELS(srcPixmap&)
srcBase& = FN GETPIXBASEADDR(srcPixmap&)
srcRow& = {[srcPixmap&] + _pmRowBytes}
srcRow& = srcRow& AND 8191
destBase& = FN GETPIXBASEADDR(destPixmap&)
destRow& = {[destPixmap&] + _pmRowBytes}
destRow& = destRow& AND 8191
'  Now I'm testing too see if the Destination Port is my visible Game Window
'  If so, adjust the destination address for the window coordinants
LONG IF srcPort&=gWindPort&
    srcStart&=srcBase&+(theRect.top%*srcRow&)+theRect.left%
    LONG IF destPort&=gWindPort&                    'Drawing To Window?
        '  Offset Graphics Target by Window Coords...
        destStart&=destBase&+((theRect.top%+gWindV%)*destRow&)+theRect.left%+gWindH%
    XELSE
        destStart&=destBase&+(theRect.top%*destRow&)+theRect.left%
    END IF
Maybe this isn't what you are trying to solve, but I'm sure it will be useful to somebody!
David Herron