> I still don't believe the problem is in the runtime. Below is a brief > demo. Do you see any flash when you run it? I have a moderately fast > machine, so that may be masking it, but it looks smooth as silk when > I run it here. Check on the sequence of building window, setting > colors, creating EF. Sure it's great to have a hackable runtime, but > if it ain't broke... :-) > > e-e > =J= a y > " > > dim as rgbcolor backRGB,foreRGB > dim r as rect > dim i > foreRGB.red = &FFFF 'Red text > //backRGB.green = &FFFF 'unREM for Green background > > setrect(r, 0, 0, 500, 200) > window 1, "EF on colored BG", @r > RGBbackColor(backRGB) > cls > rgbforecolor(foreRGB) > for i = 1 to 5 > edit field -1, "Watch for flash", (50,50)-(450, 100), _statnoframed, > _centerjust > setselect 0, 99 > edit text #1,_sysfont,40,_boldbit%¬ > //,,foreRGB, backRGB 'unREM for appearance runtime > delay 1000 > edit field close 1 > delay 1000 > next > end > Jay Thank you. The demo worked fine but It does not replicate the problem here. I get the same result in my application when I look at the window at the point of closing the Edit Field. The problem shows up during the transition between two functions. The first function contains the edit field and EDIT FIELD CLOSE, the second function puts text on the screen with no edit field. Both functions have the same RGBBACKCOLOR. The EDIT FIELD CLOSE statement must trigger a window update event with a white CLS or white PAINTRECT because I can slow down (or freeze) the action at the window update portion of my code and see a white window. I use PG:PRO and tried several combinations of window settings but got the same problem. Roberts hack gives acceptable results. However, the first pass always produces a flash but subsequent passes are fine with no white flash. I can live with that. Barrie