Edit Box Background Color

[Jim Seekamp]

Is there an easier way to change the background color of an edit box than doing the owner draw routine?

Best Regards

Jim


-------------
Jim Seekamp

[Semen Matusovski]

Jim --
this is classic way

   #Compile Exe
   #Register None
   #Dim All
   #Include "Win32Api.Inc"

   %ID_Text = 201

   CallBack Function DlgProc
      Static  hBrush As Long
      Select Case CbMsg
         Case %WM_INITDIALOG: hBrush  =  CreateSolidBrush(%Yellow)
         Case %WM_DESTROY: DeleteObject hBrush
         Case %WM_CTLCOLOREDIT
         Select Case GetDlgCtrlId(CbLparam)
            Case %ID_Text
               SetTextColor CbWparam, %Red
               SetBkColor CbWparam, %Yellow
               Function = hBrush: Exit Function
            End Select
      End Select
      
   End Function

   Function PbMain
      Local hDlg As Long
      Dialog New 0, "",,, 200, 60 To hDlg
      Control Add TextBox, hDlg, %ID_Text,"", 5, 5, 190, 50, _
         %ES_WANTRETURN Or %ES_MULTILINE, %WS_EX_CLIENTEDGE
      Dialog Show Modal hDlg Call DlgProc
   End Function

------------------

[Jim Seekamp]

Thanks for the reply, but the problem goes a bit deeper than that.
I've used the owner draw because otherwise every time you type a
character you lose the background color for that character.
This is true for your example above.
Any ideas on an easier way to keep the background color even when typing?

Best Regards

Jim


------------------
Jim Seekamp

[Semen Matusovski]

Originally posted by Jim Seekamp:
every time you type a character you lose the background color for that character.
This is true for your example above.

On my PC it's false, at least, under Win2000 and Windows95b
(did not test in others)



------------------

[Jim Seekamp]

That's interesting...
I'm using Windows 98, and it's a "bridge" between those two versions.
I have no clue why the colors change back while typing;
anybody run across this before?

Best Regards

Jim


------------------
Jim Seekamp

[K Peel]

Use:

SetBkMode hEdit, %Transparent

Also if you are using a multiline edit control, the text becomes 'garbled' under Win98, if so add:

If HiWrd(wParam) = %EN_CHANGE Then
   ' Cure multiline paint-problem
   RedrawWindow lParam, ByVal 0, 0, %RDW_ERASE Or _
   %RDW_INVALIDATE
End If

Then all should be OK.

Regards,

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[Jim Seekamp]

Thanks... I'll give that a try.

Best Regards

Jim


------------------
Jim Seekamp

[Semen Matusovski]

Originally posted by Jim Seekamp:
I'm using Windows 98

Hmm ... I don't see any troubles under Win98 SE Rus.



------------------

[Borje Hagsten]

This can happen if you select a color outside of Window's default
palette and is likely to happen if you have set the screen to only
use 16 or 256 colors.


------------------

[Jim Seekamp]

I'm using 16-bit (High) Color


------------------
Jim Seekamp

[Jim Seekamp]

well, the SetBkMode hEdit, %Transparent didn't work either.
I am using a color that is a standard winapi defined color too.
(%yellow).
Anybody else have any ideas?

Best Regards

Jim


------------------
Jim Seekamp

[Lance Edmonds]

Are you using a standard color scheme? If you change color depth, does this behavior change too? If the window is covered up and uncovered, does the control's text repaint correctly?

Did Kev's redraw code help at all, or did it have no effect what-so-ever?

More information please...!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Jim --
Do you want to say, that on your PC under Win98 doesn't work a code, which I posted in first reply, or
something doesn't work, when you try to change your own program ?


------------------

[Jim Seekamp]

Lance: thanks for the reply;
Yes, I'm using the standard default color scheme and simply changing about
20 single-line edit boxes background colors to %yellow.
In the %wm_ctlcoloredit I am setting the foreground and
background text colors to black and yellow, returning
a static brush handle to a yellow brush that was created using
createsolidbrush with %yellow as the color.
I don't have the code here with me or I'd paste it in so you
can see it. But the example looks very much like Semen's shown
in this thread.

Semen: thanks for the reply;
I'm not saying what the problem is; I have no idea.

Best Regards

Jim


------------------
Jim Seekamp

[Jim Seekamp]

This I believe is exactly the code.

static hbrush&

function whatever(byval hdlg&,byval msg&,byval wparam&,byval lparam&) as long

select case msg&
case %wm_initdialog

static hbrush&

hbrush&=createsolidbrush(%yellow)

case %wm_syscommand

if lowrd(wparam&)=%sc_close then
deleteobject hbrush&
enddialog hdlg&,1
function=1
exit function
end if

case %wm_ctlcoloredit

select case lowrd(wparam&)
case 218,222,226,230,234,238,242,246,250
settextcolor lparam&,%black
setbkcolor lparam&,%yellow
function=hbrush&
exit function
end select

end select

end function


------------------
Jim Seekamp

[Jim Seekamp]

Oh... another thing that may be important;
I created the dialog and it's controls with the dialog new,
control add, diaog show statements and sent all messages to
one particular callback



------------------
Jim Seekamp

[Chris Boss]

Jim;

Try using the RGB function instead of the color Constants and also create your BG color Brush outside of the Dialog Procedure and use a Global variable and see if that makes a difference.

The BG color Brush is the most likely suspect, IMO, since it is possible your Brush is not created yet, when the WM_CTLCOLOREDIT message is processed.

Test to make sure your Brush is a valid handle to:

If hBrush&<>0 then
    ' set the colors
else
    beep
    ' or messagebox to debug
end if

I find it hard to believe that code similiar to what Semen posted didn't work , since his method should work. Thats the proper way to set the color for controls in Windows.




------------------

[Jim Seekamp]

Chris; thanks for the response;
I find it hard to believe myself... which is why I'm
writing about it here on the BBS.
The handle most likely isn't the problem;
It's drawing the colors correctly when the dialog is opened...
it's when you TYPE OVER IT that the background color returns to
white!

Best Regards

Jim


------------------
Jim Seekamp

[This message has been edited by Jim Seekamp (edited May 04, 2000).]

[Jim Seekamp]

Chris:
I think you're right now that I think about it;
It's not using the brush to initially color the edit boxes.
I'll try it out tonight. (Don't have the code here now)

Best Regards

Jim


------------------
Jim Seekamp

[Chris Boss]

Jim;

The Windows Color messages (WM_CTRLCOLORxxxx) can be sent to your Dialog procedure "multiple" times by Windows for the same control. If for any reason it is sent and the Brush is not defined at the particular time, then it could confuse Windows.



------------------