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

WINDOWS

Change the background of an Edit Field


you can either:

1. mark the entire window as invalid (needing refresh),
in which case all the edit fields will be refreshed with the current background color;

or

2. create (or recreate) the edit field(s)
_after_ changing the background color. for example:

WINDOW 1
COLOR _zred
EDIT FIELD -1," hello ",(20,20)-(100,100),_framed
SETSELECT 0,0
EDIT FIELD 0
WINDOW FILL : REM the first edit field will display
DELAY 2000

LONG COLOR 0,0,0,0
CLS : REM try removing this "cls" to compare...
DELAY 2000

EDIT FIELD -2," goodbye ",(120,120)-(200,200),_framed
SETSELECT 0,0
EDIT FIELD 0
WINDOW FILL : REM the second field always has a black background
DELAY 2000

CLS
DELAY 2000
EDIT FIELD -1,,,, : REM re-create the first edit field
SETSELECT 0,0
EDIT FIELD 0
WINDOW FILL : REM the first field now has a black background

DELAY 3000

Bowerbird


I think if you do a create an RGB record like so:

DIM rgbrecrd.6
rgbrecrd.red = 0
rgbrecrd.green = 0
rgbrecrd.blue = 0
CALL RGBBACKCOLOR(#@rgbrecrd)

before displaying the edit field that it'll do it.

You may also need to catch updating events or you may get the same results.

Terence Jordan


here's a routine andy once provided to use for ppats.just feed it the resource number of the ppat you want.

CLEAR LOCAL FN andyppat(id)
  gandyppat&=FN GETPIXPAT(id)
  LONG IF gandyppat&
    CALL GETPORT(thePort&)
    oldPixPat&=[thePort&+_bkPat]
    LONG IF oldPixPat&
      CALL DISPOSPIXPAT(oldPixPat&)
    END IF
    CALL BACKPIXPAT(gandyppat&)
  END IF
END FN

bowerbird


Note

Thanks everyone for the replies to my question about this. I just wanted to add some more information, now that the problem is solved:

1. Both a call to RGBFORECOLOR and to SET BACKCOLOR will set the background color of the edit field correctly, but only if you call one of them immediately before creating the edit field. I had already previously set the backcolor of the window to black but the edit field showed up white until I made the backcolor call again just before creating the edit field. Maybe drawing to a window in between the background color statement and the creation of the edit field had changed some settings.

2. The edit field now will have the proper color the first time you draw the edit field--however, the first time you attempt to edit something in it, it will change to a white background (for some reason, though, it will use the correct background on subsequent edits). To prevent this, you can flag the _efClick event in your ON DIALOG handler and set the background and foreground colors of the edit field correctly every time an edit field is clicked. Now you can make the edit field colors anything you want at any time.

Mark Goodes