FB II Compiler
Make transparent Edit fields
You have to set AUTOCLIP to false after creating your edit field and then trap all keystrokes with ON EDIT so you can update the background after text is placed in the field. Something like this (sorry I don't use PG):
LOCAL FN refreshBackground
PEN 10,10, 1, 39, 0
CALL MOVETO (0,0)
CALL LINETO (500,300)
LOCAL FN doEdit
char$ = TEKEY$
TEKEY$ = char$
ON EDIT FN doEdit
WINDOW 1, "", (3,41)-(637,472)
EDIT FIELD 1, "Press COMMAND + PERIOD to end.", (10,10)-(500,200),2
AUTOCLIP = _false
I dont know you just want the background color of the edit field to match the background pattern of the window or you want to add a picture to the background.
If you want the pattern to match in PG you would choose the window menu\text&texture then choose the background that you want. In straight FB you would get the resource of the ppat that you want using ppat& GETPIXPAT(rsrcID) then CALL BACKPIXPAT(ppat&) then call RGBBACKCOLOR to match the dominant color of your ppat. If your ppat is multicolored, when you hilited the edit field only the background colors that match the windows backcolor will be hilited so be careful of the background pattern and backcolor that you use.
If you want to put a picture in the background of the edit field I dont have an easy solution for you. There is a quickdraw call that needs to be patched so that eraserect isnt called when TEUPDATE is called. There is a program on the apple website called TEOVERBACKGRND.C or something very close to this that does what you want, (if thats what you want). If never converted the program as I've wanted to do before. That and some other C code examples. If you read C thats great but even if you dont, I *think* its intuitive enough that you can extract the necessary info to pull it off.
This is a major headache. If you try to insert a character, transparent text (where white pixels are transparent) will overwrite itself without erasing. If you delete text, there is nothing to erase the white space that is created at the bottom or right of the text. About the only true transparency is related to writing to a hidden field, transferring it to an offscreen scratch world which has been refreshed with a background picture, then moving the whole thing to the screen.
You can change the background color and pattern and the text mode (from text & textures in PG) of the window, but this brings in yet another set of unique headaches. The first that comes to mind is the difficulty of selecting text when the background is something like gray and the hilite color is something like light blue or yellow.
I think you can do what you want - you just have to cheat a bit. Or think laterally, which always sounds better.
If t'were me, I'd use a TEXTBOX to draw the text to the screen, to start with. You can thus have any combination of colour you like.
Then I'd trap any click in the TEXTBOX, (or a sequence to it via a Tab) and immediately draw an EDIT FIELD, and then allow the user to edit it, When he/she finishes, I'd remove the EDIT FIELD and put the TEXTBOX back up with the new string.
Voila !! (probably)