
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
|
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
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.
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
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.
|