CEdit white

I have some read only CEdit controls on a dialog, but they appear grey. I 
would like them to be white. I tried subclassing CEdit and adding the 
following method (m_brBackgroundBrush is a plain white brush), but they are 
still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
perhaps?

BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
{
 BOOL returnVal = CEdit::OnEraseBkgnd(pDC);

 CRect rect;
 GetClientRect(&rect);

// Tile the watermark bitmap over the screen
 pDC->FillRect(&rect, &m_brBackgroundBrush);

 return returnVal;
} 


0
3/27/2007 3:42:21 PM
vc.mfc 33608 articles. 0 followers. Follow

42 Replies
1209 Views

Similar Articles

[PageSpeed] 20

"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>I have some read only CEdit controls on a dialog, but they appear grey. I 
>would like them to be white. I tried subclassing CEdit and adding the 
>following method (m_brBackgroundBrush is a plain white brush), but they are 
>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>perhaps?
>

It would probably be easier to leave the edit non-read-only and throw away 
all keystrokes.

-- David 


0
dc2983 (3206)
3/27/2007 3:51:15 PM
Try this .....

BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
{
 CBrush brNew(RGB(255,255,255));
 CBrush* pOldBrush = (CBrush*)pDC->SelectObject(&brNew);
 CRect rc;
 pDC->GetClipBox(rc);
 pDC->PatBlt(0,0,rc.Width(),rc.Height(),PATCOPY);
 pDC->SelectObject(pOldBrush);
 return TRUE;
}

"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>I have some read only CEdit controls on a dialog, but they appear grey. I 
>would like them to be white. I tried subclassing CEdit and adding the 
>following method (m_brBackgroundBrush is a plain white brush), but they are 
>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>perhaps?
>
> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
> {
> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>
> CRect rect;
> GetClientRect(&rect);
>
> // Tile the watermark bitmap over the screen
> pDC->FillRect(&rect, &m_brBackgroundBrush);
>
> return returnVal;
> }
> 


0
mubi (159)
3/27/2007 3:51:52 PM
I see that you got a couple of answers, but wouldn't it be confusing to your 
user if the edit control looked like it could be modified, and then 
couldn't?  You may want to consider using a static or just disabling the 
edit control when you don't want people to make changes.

Tom

"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>I have some read only CEdit controls on a dialog, but they appear grey. I 
>would like them to be white. I tried subclassing CEdit and adding the 
>following method (m_brBackgroundBrush is a plain white brush), but they are 
>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>perhaps?
>
> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
> {
> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>
> CRect rect;
> GetClientRect(&rect);
>
> // Tile the watermark bitmap over the screen
> pDC->FillRect(&rect, &m_brBackgroundBrush);
>
> return returnVal;
> }
> 

0
tom.nospam (3240)
3/27/2007 4:10:51 PM
The only way to do this correctly is to handle the WM_CTLCOLOR message.

Here you go

CEditWhite::CMyEdit()
{
   m_hBrush = CreateSolidBrush(RGB(255,255,255));
}

HBRUSH CEditWhite::CtlColor(CDC* /*pDC*/, UINT /*nCtlColor*/)
{
   return m_hBrush;
}


AliR.

"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>I have some read only CEdit controls on a dialog, but they appear grey. I 
>would like them to be white. I tried subclassing CEdit and adding the 
>following method (m_brBackgroundBrush is a plain white brush), but they are 
>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>perhaps?
>
> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
> {
> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>
> CRect rect;
> GetClientRect(&rect);
>
> // Tile the watermark bitmap over the screen
> pDC->FillRect(&rect, &m_brBackgroundBrush);
>
> return returnVal;
> }
> 


0
AliR3470 (3235)
3/27/2007 4:21:39 PM
Let me also add that you can do it this way.

HBRUSH CEditWhite::CtlColor(CDC* /*pDC*/, UINT /*nCtlColor*/)
{
  return (HBRUSH)GetStockObject(WHITE_BRUSH);
}

AliR.


"AliR (VC++ MVP)" <AliR@online.nospam> wrote in message 
news:nwbOh.3425$Kd3.1491@newssvr27.news.prodigy.net...
> The only way to do this correctly is to handle the WM_CTLCOLOR message.
>
> Here you go
>
> CEditWhite::CMyEdit()
> {
>   m_hBrush = CreateSolidBrush(RGB(255,255,255));
> }
>
> HBRUSH CEditWhite::CtlColor(CDC* /*pDC*/, UINT /*nCtlColor*/)
> {
>   return m_hBrush;
> }
>
>
> AliR.
>
> "GT" <ContactGT_removeme_@hotmail.com> wrote in message 
> news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>would like them to be white. I tried subclassing CEdit and adding the 
>>following method (m_brBackgroundBrush is a plain white brush), but they 
>>are still grey - any ideas? Should I overwrite the OnPaint or OnDraw 
>>method perhaps?
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>
>> CRect rect;
>> GetClientRect(&rect);
>>
>> // Tile the watermark bitmap over the screen
>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>
>> return returnVal;
>> }
>>
>
> 


0
AliR3470 (3235)
3/27/2007 5:53:48 PM
Did you actually try this code before you posted it?

AliR.

"Mubashir Khan" <mubi@yahoo.com> wrote in message 
news:uhnvtfIcHHA.984@TK2MSFTNGP04.phx.gbl...
> Try this .....
>
> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
> {
> CBrush brNew(RGB(255,255,255));
> CBrush* pOldBrush = (CBrush*)pDC->SelectObject(&brNew);
> CRect rc;
> pDC->GetClipBox(rc);
> pDC->PatBlt(0,0,rc.Width(),rc.Height(),PATCOPY);
> pDC->SelectObject(pOldBrush);
> return TRUE;
> }
>
> "GT" <ContactGT_removeme_@hotmail.com> wrote in message 
> news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>would like them to be white. I tried subclassing CEdit and adding the 
>>following method (m_brBackgroundBrush is a plain white brush), but they 
>>are still grey - any ideas? Should I overwrite the OnPaint or OnDraw 
>>method perhaps?
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>
>> CRect rect;
>> GetClientRect(&rect);
>>
>> // Tile the watermark bitmap over the screen
>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>
>> return returnVal;
>> }
>>
>
> 


0
AliR3470 (3235)
3/27/2007 7:27:34 PM
I seriously doubt this code can work.  Edit controls "optimize" repainting in a number of
ways and what you are doing will probably erase parts of the edit control that will not be
redrawn.  

You should not be using OnEraseBkgnd.  I'd think about using =WM_CTLCOLOR handlers, but
that's just an idea.  I haven't tested it.
				joe

On Tue, 27 Mar 2007 10:51:52 -0500, "Mubashir Khan" <mubi@yahoo.com> wrote:

>Try this .....
>
>BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>{
> CBrush brNew(RGB(255,255,255));
> CBrush* pOldBrush = (CBrush*)pDC->SelectObject(&brNew);
> CRect rc;
> pDC->GetClipBox(rc);
> pDC->PatBlt(0,0,rc.Width(),rc.Height(),PATCOPY);
> pDC->SelectObject(pOldBrush);
> return TRUE;
>}
>
>"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
>news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>would like them to be white. I tried subclassing CEdit and adding the 
>>following method (m_brBackgroundBrush is a plain white brush), but they are 
>>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>>perhaps?
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>
>> CRect rect;
>> GetClientRect(&rect);
>>
>> // Tile the watermark bitmap over the screen
>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>
>> return returnVal;
>> }
>> 
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/28/2007 5:58:12 AM
oops ... we are using this to change view background in one of our projects 
..... yesWM_CTLCOLOR should be the way .....
"AliR (VC++ MVP)" <AliR@online.nospam> wrote in message 
news:GeeOh.11893$Um6.1754@newssvr12.news.prodigy.net...
> Did you actually try this code before you posted it?
>
> AliR.
>
> "Mubashir Khan" <mubi@yahoo.com> wrote in message 
> news:uhnvtfIcHHA.984@TK2MSFTNGP04.phx.gbl...
>> Try this .....
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> CBrush brNew(RGB(255,255,255));
>> CBrush* pOldBrush = (CBrush*)pDC->SelectObject(&brNew);
>> CRect rc;
>> pDC->GetClipBox(rc);
>> pDC->PatBlt(0,0,rc.Width(),rc.Height(),PATCOPY);
>> pDC->SelectObject(pOldBrush);
>> return TRUE;
>> }
>>
>> "GT" <ContactGT_removeme_@hotmail.com> wrote in message 
>> news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>>would like them to be white. I tried subclassing CEdit and adding the 
>>>following method (m_brBackgroundBrush is a plain white brush), but they 
>>>are still grey - any ideas? Should I overwrite the OnPaint or OnDraw 
>>>method perhaps?
>>>
>>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>>> {
>>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>>
>>> CRect rect;
>>> GetClientRect(&rect);
>>>
>>> // Tile the watermark bitmap over the screen
>>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>>
>>> return returnVal;
>>> }
>>>
>>
>>
>
> 


0
mubi (159)
3/28/2007 9:05:51 AM
"AliR (VC++ MVP)" <AliR@online.nospam> wrote in message 
news:nwbOh.3425$Kd3.1491@newssvr27.news.prodigy.net...
> The only way to do this correctly is to handle the WM_CTLCOLOR message.
>
> Here you go
>
> CEditWhite::CMyEdit()
> {
>   m_hBrush = CreateSolidBrush(RGB(255,255,255));
> }
>
> HBRUSH CEditWhite::CtlColor(CDC* /*pDC*/, UINT /*nCtlColor*/)
> {
>   return m_hBrush;
> }

I have used this exact code and it doesn't work - everything is still grey! 
Am I missing a setting somewhere?! 


0
3/28/2007 9:26:12 AM
"Tom Serface" <tom.nospam@camaswood.com> wrote in message 
news:F3165BB0-CFF2-46E2-8F35-34B6067AE652@microsoft.com...
>I see that you got a couple of answers, but wouldn't it be confusing to 
>your user if the edit control looked like it could be modified, and then 
>couldn't?  You may want to consider using a static or just disabling the 
>edit control when you don't want people to make changes.

Potentially, yes, but the rest of the window is white and they just look 
silly!.This is a floating 'results' screen which is always presents 
numerical results that are not editable. I have tried using CtlColor method 
and the OnEraseBkgnd method, but I can't stop them from being grey. 


0
3/28/2007 10:29:36 AM
"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>I have some read only CEdit controls on a dialog, but they appear grey. I 
>would like them to be white. I tried subclassing CEdit and adding the 
>following method (m_brBackgroundBrush is a plain white brush), but they are 
>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>perhaps?
>
> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
> {
> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>
> CRect rect;
> GetClientRect(&rect);
>
> // Tile the watermark bitmap over the screen
> pDC->FillRect(&rect, &m_brBackgroundBrush);
>
> return returnVal;
> }

OK, I've managed to get the background to change color. Don't need to 
specialise from CEdit at all - just use the CtlColor method in the main 
dialog code, a snippet:

HBRUSH ViewSummary::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
 switch (nCtlColor)
 {
  case CTLCOLOR_EDIT: // 1
  case CTLCOLOR_STATIC: // 6
   // Set color to green on black and return the background brush.
   pDC->SetTextColor(RGB(0, 0, 0));
   pDC->SetBkColor(RGB(255, 255, 255));
   pDC->getb
   return m_brBackgroundBrush;


Now I would like to take this further and use the system theme background 
color, so my background window color matched all other windows on the 
system. How can I get the RGB value for the current theme background color 
and text color? 


0
3/28/2007 12:49:11 PM
"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:460a6400$0$26117$c3e8da3@news.astraweb.com...
> Now I would like to take this further and use the system theme background 
> color, so my background window color matched all other windows on the 
> system. How can I get the RGB value for the current theme background color 
> and text color?

GetSysColor(COLOR_WINDOW) and
GetSysColor(COLOR_WINDOWTEXT)

-- David 


0
dc2983 (3206)
3/28/2007 1:23:35 PM
That's all fine, but now if you want another window to have the same type of 
edit control you will have to duplicate this code again in that other 
dialog.  Wouldn't it be easier if it was in the edit control?

AliR.


"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
news:460a6400$0$26117$c3e8da3@news.astraweb.com...
> "GT" <ContactGT_removeme_@hotmail.com> wrote in message 
> news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>would like them to be white. I tried subclassing CEdit and adding the 
>>following method (m_brBackgroundBrush is a plain white brush), but they 
>>are still grey - any ideas? Should I overwrite the OnPaint or OnDraw 
>>method perhaps?
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>
>> CRect rect;
>> GetClientRect(&rect);
>>
>> // Tile the watermark bitmap over the screen
>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>
>> return returnVal;
>> }
>
> OK, I've managed to get the background to change color. Don't need to 
> specialise from CEdit at all - just use the CtlColor method in the main 
> dialog code, a snippet:
>
> HBRUSH ViewSummary::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
> {
> switch (nCtlColor)
> {
>  case CTLCOLOR_EDIT: // 1
>  case CTLCOLOR_STATIC: // 6
>   // Set color to green on black and return the background brush.
>   pDC->SetTextColor(RGB(0, 0, 0));
>   pDC->SetBkColor(RGB(255, 255, 255));
>   pDC->getb
>   return m_brBackgroundBrush;
>
>
> Now I would like to take this further and use the system theme background 
> color, so my background window color matched all other windows on the 
> system. How can I get the RGB value for the current theme background color 
> and text color?
> 


0
AliR3470 (3235)
3/28/2007 2:40:51 PM
Don't put this code in your view.  Subclass the edit control by using =WM_CTLCOLOR in the
control.
				joe

On Wed, 28 Mar 2007 13:49:11 +0100, "GT" <ContactGT_removeme_@hotmail.com> wrote:

>"GT" <ContactGT_removeme_@hotmail.com> wrote in message 
>news:46093aa8$0$17256$c3e8da3@news.astraweb.com...
>>I have some read only CEdit controls on a dialog, but they appear grey. I 
>>would like them to be white. I tried subclassing CEdit and adding the 
>>following method (m_brBackgroundBrush is a plain white brush), but they are 
>>still grey - any ideas? Should I overwrite the OnPaint or OnDraw method 
>>perhaps?
>>
>> BOOL CEditWhite::OnEraseBkgnd(CDC* pDC)
>> {
>> BOOL returnVal = CEdit::OnEraseBkgnd(pDC);
>>
>> CRect rect;
>> GetClientRect(&rect);
>>
>> // Tile the watermark bitmap over the screen
>> pDC->FillRect(&rect, &m_brBackgroundBrush);
>>
>> return returnVal;
>> }
>
>OK, I've managed to get the background to change color. Don't need to 
>specialise from CEdit at all - just use the CtlColor method in the main 
>dialog code, a snippet:
>
>HBRUSH ViewSummary::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
>{
> switch (nCtlColor)
> {
>  case CTLCOLOR_EDIT: // 1
>  case CTLCOLOR_STATIC: // 6
>   // Set color to green on black and return the background brush.
>   pDC->SetTextColor(RGB(0, 0, 0));
>   pDC->SetBkColor(RGB(255, 255, 255));
>   pDC->getb
>   return m_brBackgroundBrush;
>
>
>Now I would like to take this further and use the system theme background 
>color, so my background window color matched all other windows on the 
>system. How can I get the RGB value for the current theme background color 
>and text color? 
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/28/2007 5:03:44 PM
Joe, doesn't that "depend".  For example, if you want to do a similar 
background on more than one  control, you could have the parent handle the 
messages for the controls.  The program can call pWnd->GetDlgCtrlID() to 
figure out which control is requesting color and the parent can handle it 
for multiple controls in a switch.

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:lt7l035k91gjmaoqb20gkhuuimc72tfklm@4ax.com...
> Don't put this code in your view.  Subclass the edit control by using 
> =WM_CTLCOLOR in the
> control.
> joe

0
tom.nospam (3240)
3/28/2007 5:54:46 PM
"AliR (VC++ MVP)" <AliR@online.nospam> wrote in message 
news:T7vOh.9735$JZ3.6074@newssvr13.news.prodigy.net...
> That's all fine, but now if you want another window to have the same type 
> of edit control you will have to duplicate this code again in that other 
> dialog.  Wouldn't it be easier if it was in the edit control?

Would be much easier and that is what I tried originally, but it doesn't 
work! The edit control stays grey! 


0
3/29/2007 10:36:45 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:lt7l035k91gjmaoqb20gkhuuimc72tfklm@4ax.com...
> Don't put this code in your view.  Subclass the edit control by using 
> =WM_CTLCOLOR in the
> control.
> joe

I tried this (as posted earlier in this thread) but it doesn't work - 
control stays grey! 


0
3/29/2007 10:37:25 AM
It works when I try it.

Here is what I did. (Visual Studio 2003)

http://www.learnstar.com/AliR/EditReadOnly.zip

AliR.

"GT" <ContactGT_remove_@hotmail.com> wrote in message 
news:460b9697$0$7321$c3e8da3@news.astraweb.com...
> "AliR (VC++ MVP)" <AliR@online.nospam> wrote in message 
> news:T7vOh.9735$JZ3.6074@newssvr13.news.prodigy.net...
>> That's all fine, but now if you want another window to have the same type 
>> of edit control you will have to duplicate this code again in that other 
>> dialog.  Wouldn't it be easier if it was in the edit control?
>
> Would be much easier and that is what I tried originally, but it doesn't 
> work! The edit control stays grey!
> 


0
AliR3470 (3235)
3/29/2007 3:18:08 PM
Actually, if I wanted to put a similar background in a lot of controls, I'd subclass the
control, put an =WM_CTLCOLOR handler in, and make all my controls be instances of that
subclass.  

I consider the handling of WM_CTLCOLOR in the parent, and ESPECIALLY the situation with a
switch based on control IDs, to be very non-moduler, non-OO, and essentially bad style. It
took me years to overcome this sort of bad design that Petzold's book taught.
					joe

On Wed, 28 Mar 2007 10:54:46 -0700, "Tom Serface" <tom.nospam@camaswood.com> wrote:

>Joe, doesn't that "depend".  For example, if you want to do a similar 
>background on more than one  control, you could have the parent handle the 
>messages for the controls.  The program can call pWnd->GetDlgCtrlID() to 
>figure out which control is requesting color and the parent can handle it 
>for multiple controls in a switch.
>
>Tom
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:lt7l035k91gjmaoqb20gkhuuimc72tfklm@4ax.com...
>> Don't put this code in your view.  Subclass the edit control by using 
>> =WM_CTLCOLOR in the
>> control.
>> joe
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/30/2007 3:49:07 AM
A disabled edit control returns CTLCOLOR_STATIC calls.
				joe

On Thu, 29 Mar 2007 11:37:25 +0100, "GT" <ContactGT_remove_@hotmail.com> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:lt7l035k91gjmaoqb20gkhuuimc72tfklm@4ax.com...
>> Don't put this code in your view.  Subclass the edit control by using 
>> =WM_CTLCOLOR in the
>> control.
>> joe
>
>I tried this (as posted earlier in this thread) but it doesn't work - 
>control stays grey! 
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/30/2007 3:49:32 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:r52p03plbc7612k9jgdkfhcohb0996mt4i@4ax.com...
>A disabled edit control returns CTLCOLOR_STATIC calls.

Then wouldn't the easy way to fix this problem is to override OnCtlColor, 
see if the color being requested is a static, then test if the hwnd is an 
EDIT (by calling GetClassName(), and if so, then it must be a disabled edit, 
so return WHITE?

Thanks,
David 


0
dc2983 (3206)
3/30/2007 4:00:54 AM
I guess, again, it all depends.  If you're talking about a control you use 
all over, you're right, creating an object would be a good idea. 
Subclassing several controls on a dialog just to change the background seems 
kind like overkill to me.  If it's just for the one dialog then 
encapsulating the behavior in that dialog wouldn't be that bad of design in 
my opinion.  Of course, the nice thing about all this stuff is there are 
lots of ways to solve the same problem.  I don't remember Petzold's book.  I 
had a copy, but I didn't read it and that was a really long time ago :o)

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:222p031sgit3teipu79422jg2tfthnomjv@4ax.com...
> Actually, if I wanted to put a similar background in a lot of controls, 
> I'd subclass the
> control, put an =WM_CTLCOLOR handler in, and make all my controls be 
> instances of that
> subclass.
>
> I consider the handling of WM_CTLCOLOR in the parent, and ESPECIALLY the 
> situation with a
> switch based on control IDs, to be very non-moduler, non-OO, and 
> essentially bad style. It
> took me years to overcome this sort of bad design that Petzold's book 
> taught.
> joe
>

0
tom.nospam (3240)
3/30/2007 5:49:21 AM
I consider subclassing a control to be such a natural paradigm that it never occurs to me
to think of it as unusual.  

I learned programming from Petzold, and it took me years to figure out how many style
problems he teaches.  The problem was that I was already an experienced programmer, and I
found WIndows to be a weird and unpleasant system to program because everything had to be
global variables, you lost context all over the place, etc.  It took me about three years
to get deeply enough into Windows to recognize that none of these limitations existed, and
they were artifacts of the poor programming style Petzold taught.
					joe

On Thu, 29 Mar 2007 22:49:21 -0700, "Tom Serface" <tom.nospam@camaswood.com> wrote:

>I guess, again, it all depends.  If you're talking about a control you use 
>all over, you're right, creating an object would be a good idea. 
>Subclassing several controls on a dialog just to change the background seems 
>kind like overkill to me.  If it's just for the one dialog then 
>encapsulating the behavior in that dialog wouldn't be that bad of design in 
>my opinion.  Of course, the nice thing about all this stuff is there are 
>lots of ways to solve the same problem.  I don't remember Petzold's book.  I 
>had a copy, but I didn't read it and that was a really long time ago :o)
>
>Tom
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:222p031sgit3teipu79422jg2tfthnomjv@4ax.com...
>> Actually, if I wanted to put a similar background in a lot of controls, 
>> I'd subclass the
>> control, put an =WM_CTLCOLOR handler in, and make all my controls be 
>> instances of that
>> subclass.
>>
>> I consider the handling of WM_CTLCOLOR in the parent, and ESPECIALLY the 
>> situation with a
>> switch based on control IDs, to be very non-moduler, non-OO, and 
>> essentially bad style. It
>> took me years to overcome this sort of bad design that Petzold's book 
>> taught.
>> joe
>>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/30/2007 4:32:25 PM
I don't think it's unusal at all.  I typically end up doing several 
specialized controls for applications.

I think, for it's time the Petzold book was very handy for a lot of people 
trying to use the SDK in a non-OOP world.  I'm sure we all still have bad 
habits.  Every time someone reviews some of my code I learn something new 
about a better way to do something or other.  I had similar problems with 
learning the Windows SDK until VC++ 1.0 came out and then I was delighted to 
see I could actually do interesting UI with MFC.  That's probably why I'm 
still so loyal to it.  It takes a while to learn MFC, but not so long as 
learning what is behind it.

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:uneq03lctf7fd1q4obc9qt7vqtbpjun2ao@4ax.com...
>I consider subclassing a control to be such a natural paradigm that it 
>never occurs to me
> to think of it as unusual.
>
> I learned programming from Petzold, and it took me years to figure out how 
> many style
> problems he teaches.  The problem was that I was already an experienced 
> programmer, and I
> found WIndows to be a weird and unpleasant system to program because 
> everything had to be
> global variables, you lost context all over the place, etc.  It took me 
> about three years
> to get deeply enough into Windows to recognize that none of these 
> limitations existed, and
> they were artifacts of the poor programming style Petzold taught.
> joe

0
tom.nospam (3240)
3/30/2007 6:17:58 PM
It taught basic Windows API interfacing, and something about graphics, but I'd come out of
an OO world and found Windows very unpleasant.  Today, if I were forced to program in the
raw Win32 API, I'd program a lot differently than I programmed in 1990.

In the Win32 API course I taught, by Wednesday, doing a lab every hour or so, by Wednesday
we almost had a simple application running.  It didn't have MDI, it didn't have a toolbar,
it didn't have a status bar, it didn't have flyover help, etc., but it almost resembled a
passable application.

In the MFC course I taught, we had a full-fledged, MDI app, with toolbars, menus,
automatic menu enabling, status bar, flyover help, etc. five minutes after the students
log on.   I basically do not believe in writing apps in the raw Win32 API.
					joe

On Fri, 30 Mar 2007 11:17:58 -0700, "Tom Serface" <tom.nospam@camaswood.com> wrote:

>I don't think it's unusal at all.  I typically end up doing several 
>specialized controls for applications.
>
>I think, for it's time the Petzold book was very handy for a lot of people 
>trying to use the SDK in a non-OOP world.  I'm sure we all still have bad 
>habits.  Every time someone reviews some of my code I learn something new 
>about a better way to do something or other.  I had similar problems with 
>learning the Windows SDK until VC++ 1.0 came out and then I was delighted to 
>see I could actually do interesting UI with MFC.  That's probably why I'm 
>still so loyal to it.  It takes a while to learn MFC, but not so long as 
>learning what is behind it.
>
>Tom
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:uneq03lctf7fd1q4obc9qt7vqtbpjun2ao@4ax.com...
>>I consider subclassing a control to be such a natural paradigm that it 
>>never occurs to me
>> to think of it as unusual.
>>
>> I learned programming from Petzold, and it took me years to figure out how 
>> many style
>> problems he teaches.  The problem was that I was already an experienced 
>> programmer, and I
>> found WIndows to be a weird and unpleasant system to program because 
>> everything had to be
>> global variables, you lost context all over the place, etc.  It took me 
>> about three years
>> to get deeply enough into Windows to recognize that none of these 
>> limitations existed, and
>> they were artifacts of the poor programming style Petzold taught.
>> joe
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
3/30/2007 8:44:00 PM
On Mar 28, 12:54 pm, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> Joe, doesn't that "depend".  For example, if you want to do a similar
> background on more than one  control, you could have the parent handle the
> messages for the controls.  The program can call pWnd->GetDlgCtrlID() to
> figure out which control is requesting color and the parent can handle it
> for multiple controls in a switch.
>

It doesnt sound right to me. This is exact opposite of OOP. If you
want to do this way, it will be natural to simply derive a class from
CEdit and expose color property rather than an external object to take
over part of control's functionality.

---
Ajay

0
ajaykalra (6841)
3/31/2007 4:16:43 AM
I'm not sure what it has to do with OOP, but  the good news is you can do it 
either way so ...

Tom

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:1175314602.985182.282140@y80g2000hsf.googlegroups.com...
> On Mar 28, 12:54 pm, "Tom Serface" <tom.nos...@camaswood.com> wrote:
>> Joe, doesn't that "depend".  For example, if you want to do a similar
>> background on more than one  control, you could have the parent handle 
>> the
>> messages for the controls.  The program can call pWnd->GetDlgCtrlID() to
>> figure out which control is requesting color and the parent can handle it
>> for multiple controls in a switch.
>>
>
> It doesnt sound right to me. This is exact opposite of OOP. If you
> want to do this way, it will be natural to simply derive a class from
> CEdit and expose color property rather than an external object to take
> over part of control's functionality.
>
> ---
> Ajay
> 

0
tom.nospam (3240)
3/31/2007 5:39:36 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:222p031sgit3teipu79422jg2tfthnomjv@4ax.com...
> Actually, if I wanted to put a similar background in a lot of controls, 
> I'd subclass the
> control, put an =WM_CTLCOLOR handler in, and make all my controls be 
> instances of that
> subclass.
>
> I consider the handling of WM_CTLCOLOR in the parent, and ESPECIALLY the 
> situation with a
> switch based on control IDs, to be very non-moduler, non-OO, and 
> essentially bad style. It
> took me years to overcome this sort of bad design that Petzold's book 
> taught.
> joe

In this case I have a dialog with a number of static 'labels' controls and 
some read only edit boxes, which have the properties changed to hide the box 
outline. Nothing on the modeless dialog is editable, so there should be no 
confusion over the purpose of the edit boxes. I want the background on 
everything to be the system background colour. If I subclass the CEdit class 
I can use that for my edit boxes, but I don't have controls for the static 
labels, so I have no objects of which I can change type. To implement a 
generic CStatic would mean putting resource IDs (other than IDC_STATIC) on 
all my dialog labels and manually implementing the control variables for 
them all. Much easier to just handle the CTL_COLOR message in one place for 
all controls in the dialog in this particular case. 


0
3/31/2007 10:02:08 AM
> I'm not sure what it has to do with OOP

A control doing its own painting and exposing the color as a property
is normal OOP.  Some other object doing it for it would bean example
of non OO. You will have to jump thru hoops to do this in .Net(much
stronger OO than MFC) the way you are suggesting it.


My .02.

---
Ajay

0
ajaykalra (6841)
3/31/2007 11:49:19 AM
The control is doing it's own painting.  In this case the dialog is just 
providing it with a brush color.  The dialog tells it's controls lots of 
things, like what text to display, whether to be enabled or disabled, it 
shows them and hides them, tells them what tooltip to display, etc.

Tom

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:1175341759.571244.314880@o5g2000hsb.googlegroups.com...
>> I'm not sure what it has to do with OOP
>
> A control doing its own painting and exposing the color as a property
> is normal OOP.  Some other object doing it for it would bean example
> of non OO. You will have to jump thru hoops to do this in .Net(much
> stronger OO than MFC) the way you are suggesting it.
>
>
> My .02.
>
> ---
> Ajay
> 

0
tom.nospam (3240)
3/31/2007 1:59:56 PM
On Mar 31, 8:59 am, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> The control is doing it's own painting.

Sorry, It seems I misunderstood you.

---
Ajay

0
ajaykalra (6841)
3/31/2007 5:03:02 PM
"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:1175341759.571244.314880@o5g2000hsb.googlegroups.com...
>> I'm not sure what it has to do with OOP
>
> A control doing its own painting and exposing the color as a property
> is normal OOP.  Some other object doing it for it would bean example
> of non OO. You will have to jump thru hoops to do this in .Net(much
> stronger OO than MFC) the way you are suggesting it.

I think you just sparked the old "is it an object or an attribute" 
discussion. If 'it' is significant enought to have its own operations and 
attributes, then you have an object (and Class). If not, then you just have 
an attribute. 


0
3/31/2007 7:09:12 PM
Ajay Kalra wrote:

> On Mar 31, 8:59 am, "Tom Serface" <tom.nos...@camaswood.com> wrote:
> 
>>The control is doing it's own painting.
> 
> 
> Sorry, It seems I misunderstood you.


Ajay:

I don't think you did. The control does paint itself, but it asks the 
parent for the color. This is non-OOP, but can be convenient in one-off 
situations. IMHO, it is different from showing or enabling, because 
these actions are initiated by the parent, in a correct OOP fashion.

David Wilkinson

0
no-reply8010 (1791)
3/31/2007 7:16:21 PM
On Mar 31, 2:16 pm, David Wilkinson <no-re...@effisols.com> wrote:
> Ajay Kalra wrote:
> > On Mar 31, 8:59 am, "Tom Serface" <tom.nos...@camaswood.com> wrote:
>
> >>The control is doing it's own painting.
>
> > Sorry, It seems I misunderstood you.
>
> Ajay:
>
> I don't think you did. The control does paint itself, but it asks the
> parent for the color.

Which can be avoided (and should be in true OOP sense) by having
control handle reflection. Control can have a property on it which
sets the color making it OO.

> This is non-OOP, but can be convenient in one-off
> situations.

I agree.

>IMHO, it is different from showing or enabling, because
> these actions are initiated by the parent, in a correct OOP fashion.

It is very different. Enabling etc are essentially properties on the
control and are within OP scope.

---
Ajay



0
ajaykalra (6841)
3/31/2007 10:33:23 PM
> I think you just sparked the old "is it an object or an attribute"
> discussion. If 'it' is significant enought to have its own operations and
> attributes, then you have an object (and Class). If not, then you just have
> an attribute.

I have no idea what you are talking about.

---
Ajay


0
ajaykalra (6841)
3/31/2007 10:34:42 PM
That's true GT.  You do have an object regardless (CEdit, CStatic, etc.) 
however we were debating over whether or not it's OK for the parent 
container (the dialog) to tell the objects what color to use on their 
backgrounds.  I think Ajay and were just confusing each other again :o)

Tom

"GT" <ContactGT_remove_@hotmail.com> wrote in message 
news:460eb127$0$461$c3e8da3@news.astraweb.com...
> "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
> news:1175341759.571244.314880@o5g2000hsb.googlegroups.com...
>>> I'm not sure what it has to do with OOP
>>
>> A control doing its own painting and exposing the color as a property
>> is normal OOP.  Some other object doing it for it would bean example
>> of non OO. You will have to jump thru hoops to do this in .Net(much
>> stronger OO than MFC) the way you are suggesting it.
>
> I think you just sparked the old "is it an object or an attribute" 
> discussion. If 'it' is significant enought to have its own operations and 
> attributes, then you have an object (and Class). If not, then you just 
> have an attribute.
> 

0
tom.nospam (3240)
4/1/2007 3:41:10 AM
Of course we do this with all kinds of things.  We tell the controls what 
text to display, for example.  I think we just have a disagreement on style. 
To be honest, I have derived controls that I use all over the place ... for 
example a CStatic that is easy to change the font or background color.  Of 
course, the dialog sets the color for the CStatic (derived) in it's 
OnInitDialog function.

It could be that it's just convenient.  I confess that my focus is more on 
making good looking applications that work than it is on the letter of the 
OOP laws :o)

Also, in this case the action is not initiated by the parent.  The control 
asks what color to use and the parent just intercepts the request and fills 
in the blank. Unless I'm misunderstanding how it works under the covers.

Tom

"David Wilkinson" <no-reply@effisols.com> wrote in message 
news:uxOEgC8cHHA.3408@TK2MSFTNGP03.phx.gbl...

> Ajay:
>
> I don't think you did. The control does paint itself, but it asks the 
> parent for the color. This is non-OOP, but can be convenient in one-off 
> situations. IMHO, it is different from showing or enabling, because these 
> actions are initiated by the parent, in a correct OOP fashion.
>
> David Wilkinson
> 

0
tom.nospam (3240)
4/1/2007 3:44:45 AM
"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:1175380482.503987.162790@n76g2000hsh.googlegroups.com...
>
>> I think you just sparked the old "is it an object or an attribute"
>> discussion. If 'it' is significant enought to have its own operations and
>> attributes, then you have an object (and Class). If not, then you just 
>> have
>> an attribute.
>
> I have no idea what you are talking about.

Well, if you have no idea what I am talking about, then you are in no 
position to lecture anybody on OO programming!! The topic I have just raised 
is in the introduction section of the OO/UML courses I run! We discuss, 
"What is an object", then "What is a class", then how to decide if something 
is an object on its own , or just an attribute of another class. 


0
4/2/2007 9:52:25 AM
"Tom Serface" <tom.nospam@camaswood.com> wrote in message 
news:DEF471E5-CC05-4CF7-8961-008415BC7D4A@microsoft.com...
> That's true GT.  You do have an object regardless (CEdit, CStatic, etc.) 
> however we were debating over whether or not it's OK for the parent 
> container (the dialog) to tell the objects what color to use on their 
> backgrounds.  I think Ajay and were just confusing each other again :o)

Actually I'm not yet convinced that we have as many objects as it appears. 
My dialog has 9 CEdit boxes that are definitely objects (3x3 grid). I also 
have 6 'labels' (3 top, 3 left labels). These labels are added to the dialog 
through the toolbox, so exist as a line of code in the project resource 
file. They are just static labels and I define no control variables for 
them. As they are not instantiated in my code, I have no type (class) for 
them, so from my code's point of view they are simply a part of the resource 
that forms the dialog, the drawing of which is handled be the 
drawing/rendering operations on the CDialog class. Should I choose to 
instantiate an object for one of these controls, it would be a CStatic (or 
derivative), but I don't do this, so my dialog consists of a CDialog 
(derivative) instance and 6 CEdit instances - 7 objects in total.

My knowledge of the inner workings of the MFC fails me here as I don't know 
how these label 'things' are actually rendered on the screen. Are they drawn 
as part of the CDialog's Paint method, or does the MFC instantiate CStatic 
objects for me and tell them to draw themselves. The first option here means 
that from an OO point of view, they are not objects, but attributes of the 
CDialog. The second option here means that they are transient objects and 
have attributes and operations of their own. I suspect the latter, but when 
modelling an instance diagram for this dialog, I would be modelling 7 
objects.

I have commented on Ajay's reply in another message. Perhaps a little 
harshly, but he started to tell us what makes good OOP, then said he doesn't 
understand basic OOP - a bit odd! I suspect he is using the term OOP, when 
he actually means MFC coding practice. 


0
4/2/2007 10:08:52 AM
"GT" <ContactGT_remove_@hotmail.com> wrote in message 
news:4610d64d$0$24409$c3e8da3@news.astraweb.com...
> "Tom Serface" <tom.nospam@camaswood.com> wrote in message 
> news:DEF471E5-CC05-4CF7-8961-008415BC7D4A@microsoft.com...
> My knowledge of the inner workings of the MFC fails me here as I don't 
> know how these label 'things' are actually rendered on the screen. Are 
> they drawn as part of the CDialog's Paint method, or does the MFC 
> instantiate CStatic objects for me and tell them to draw themselves. The 
> first option here means that from an OO point of view, they are not 
> objects, but attributes of the CDialog. The second option here means that 
> they are transient objects and have attributes and operations of their 
> own. I suspect the latter, but when modelling an instance diagram for this 
> dialog, I would be modelling 7 objects.
>

Without using MFC, the "label things" are HWND's with a classname of 
"STATIC".  The fact that they have a classname of STATIC means they have a 
WindowProc which contains code that paints "label things".  For any HWND 
(including those with a classname of "STATIC"), you can "subclass" it by 
replacing its WindowProc with your own.  So in MyStaticWindowProc, you can 
do things like paint label things as foobar things, if you want.  You can 
change the background color to white, if you want.  So to the extent you 
consider an HWND an object that you subclass by replacing its WindowProc, 
then yes,  every control in your dialog is an object.  But there is no 
physical C++ object.  Indeed, most people don't realize that Windows 
contains many classes like HWND, HDC, HBRUSH, etc. but they are not called 
"classes" because OOP languages had not been created at the time, and 
Microsoft was forced to do crazy things like replacing WindowProcs instead 
of deriving new classes to affect new behavior.

Fast forward a few years.  OOP languages prevail.  MFC now lets you add a 
phyiscal C++ object (e.g. CStatic) to any number of HWND's in your dialog. 
Under the covers, it performs the subclass step (see above) using e.g. 
CStatic::WindowProc.

So whether or not you think there is an object there simply by having a 
STATIC, or if you actually need a physical C++ class like CStatic in order 
for it to count as an object is what we're debating here.


-- David 


0
dc2983 (3206)
4/2/2007 12:55:36 PM
>> My knowledge of the inner workings of the MFC fails me here as I don't 
>> know how these label 'things' are actually rendered on the screen. Are 
>> they drawn as part of the CDialog's Paint method, or does the MFC 
>> instantiate CStatic objects for me and tell them to draw themselves. The 
>> first option here means that from an OO point of view, they are not 
>> objects, but attributes of the CDialog. The second option here means that 
>> they are transient objects and have attributes and operations of their 
>> own. I suspect the latter, but when modelling an instance diagram for 
>> this dialog, I would be modelling 7 objects.
>
> Without using MFC, the "label things" are HWND's with a classname of 
> "STATIC".  The fact that they have a classname of STATIC means they have a 
> WindowProc which contains code that paints "label things".  For any HWND 
> (including those with a classname of "STATIC"), you can "subclass" it by 
> replacing its WindowProc with your own.  So in MyStaticWindowProc, you can 
> do things like paint label things as foobar things, if you want.  You can 
> change the background color to white, if you want.  So to the extent you 
> consider an HWND an object that you subclass by replacing its WindowProc, 
> then yes,  every control in your dialog is an object.  But there is no 
> physical C++ object.  Indeed, most people don't realize that Windows 
> contains many classes like HWND, HDC, HBRUSH, etc. but they are not called 
> "classes" because OOP languages had not been created at the time, and 
> Microsoft was forced to do crazy things like replacing WindowProcs instead 
> of deriving new classes to affect new behavior.

Interesting background info - thanks. 


0
4/2/2007 1:32:49 PM
Hi GT,

David is write, they are still objects even though you don't have to do 
anything with them.  However, I think you will want to change the IDs away 
from IDC_STATIC (basically -1) and make them something else so you could 
eventually change them the same way you do your edit controls.

I mostly just leave the labels as statics (without their own ID's) when I 
don't have to enable or disable or change the text or attributes of the 
control.  That isn't very often these days.

Don't worry about Ajay, he can dish it out, but he can also take it :o)

Tom

"GT" <ContactGT_remove_@hotmail.com> wrote in message 
news:4610d64d$0$24409$c3e8da3@news.astraweb.com...

> Actually I'm not yet convinced that we have as many objects as it appears. 
> My dialog has 9 CEdit boxes that are definitely objects (3x3 grid). I also 
> have 6 'labels' (3 top, 3 left labels). These labels are added to the 
> dialog through the toolbox, so exist as a line of code in the project 
> resource file. They are just static labels and I define no control 
> variables for them. As they are not instantiated in my code, I have no 
> type (class) for them, so from my code's point of view they are simply a 
> part of the resource that forms the dialog, the drawing of which is 
> handled be the drawing/rendering operations on the CDialog class. Should I 
> choose to instantiate an object for one of these controls, it would be a 
> CStatic (or derivative), but I don't do this, so my dialog consists of a 
> CDialog (derivative) instance and 6 CEdit instances - 7 objects in total.
>
> My knowledge of the inner workings of the MFC fails me here as I don't 
> know how these label 'things' are actually rendered on the screen. Are 
> they drawn as part of the CDialog's Paint method, or does the MFC 
> instantiate CStatic objects for me and tell them to draw themselves. The 
> first option here means that from an OO point of view, they are not 
> objects, but attributes of the CDialog. The second option here means that 
> they are transient objects and have attributes and operations of their 
> own. I suspect the latter, but when modelling an instance diagram for this 
> dialog, I would be modelling 7 objects.
>
> I have commented on Ajay's reply in another message. Perhaps a little 
> harshly, but he started to tell us what makes good OOP, then said he 
> doesn't understand basic OOP - a bit odd! I suspect he is using the term 
> OOP, when he actually means MFC coding practice.
> 

0
tom.nospam (3240)
4/2/2007 1:44:08 PM
Reply:

Similar Artilces:

CEdit Control
I have an SDI app a with CFormView. The CFormView has multiple edit controls on it. What is the best way to save the data for the conrol ie what message do I need to handle. There are one case I'm concerned about: 1. The user has selected save or exit from the top menu. I have tried handling the kill focus message for the control but if you have make changes to the edit box and have not exited it before doing a File | Save the kill focus message is not send and I don't save the data. I don't really want to update on every keystroke in the edit control since I only care ...

CEdit
Hi All, I would like to change the appereance of CEdit's buttons. Ideally, I would like to replace them with my own buttons (derived from CBitmapButton). I know all about the limitations of CEdit in terms of attempting to change the way it draws itself so before I even try to do something like this I would like to know if anyone here has any experience with that and if this scenario is even supported by CEdit. Furthermore, I would also like to draw its scrollbars. If I can't take over the drawing of its buttons and scroll bars, is it at least possible to change thei...

How to change the CEdit's caret?
Hi, I have an edit control for which I can change its font depending on a checkbox status. How can I change the caret back and forth depending on which font is set in the CEdit control? I appreciate any help. Thanks, Geo I don't think this is possible for a CEdit. If I were trying it, I'd subclass the CEdit and override the OnSetFocus/OnKillFocus, and do caret manipulations there, but at this point you're trying to deal with fooling the CEdit into doing what you want, and that is likely to be unsuccessful. joe On Fri, 25 Nov 2005 19:46:02 -0800, Geo <Geo@discuss...

Subclassing CEdit in CComboBox
Hello, I'm trying to make a CComboBox derived control where the text shown in the selection box is different from any text in the combo's list. I've been following Microsoft Knowledge Base Article - 174667 (HOWTO: Subclass CListBox and CEdit Inside of CComboBox), which suggests using OnCtlColor() to get a handle for the edit control inside the combo box. My CMyComboBox is created dynamically at runtime, and I've noticed that their approach only works when the combo box is created with the CBS_DROPDOWN style. With CBS_DROPDOWNLIST the OnCtlColor() handler is never called at a...

appending to CEdit
I have a CEdit control and I want to append text to it as follows: void CSerialPortDlg::debugf(char* format, ...) { char buf[4096]; // should be big enough va_list arglist; va_start( arglist, format ); vsprintf( buf, format, arglist ); va_end( arglist ); if( GetSafeHwnd() && m_edit.GetSafeHwnd() ) { m_edit.LineScroll( m_edit.GetLineCount() ); m_edit.SetSel( -1, 0, TRUE ); m_edit.ReplaceSel( buf ); } } This works fine until there is a lot of text in the CEdit control. After, oh I don't know, maybe 64k of data or so, it no longer adds any...

CEdit white
I have some read only CEdit controls on a dialog, but they appear grey. I would like them to be white. I tried subclassing CEdit and adding the following method (m_brBackgroundBrush is a plain white brush), but they are still grey - any ideas? Should I overwrite the OnPaint or OnDraw method perhaps? BOOL CEditWhite::OnEraseBkgnd(CDC* pDC) { BOOL returnVal = CEdit::OnEraseBkgnd(pDC); CRect rect; GetClientRect(&rect); // Tile the watermark bitmap over the screen pDC->FillRect(&rect, &m_brBackgroundBrush); return returnVal; } "GT" <ContactGT_removeme_@...

How to Set/Change Transparency to CEdit control?
Hi, How to set/change Transparency to Custom Edit control. Can I use SetLayeredWindowAttributes() to set alpha factor for CEdit control? Can I use WS_EX_LAYERED style to child (CEdit) controls? Or should I use GDI+ library feature (Gdiplus::SolidBrush(Gdiplus::Color()). At present both ways are not working for me. Since the edit control is drawn with GDI, invoking a GDI+ mechanism is not going to be terribly successful. While you might consider subclassing the edit control and returning a NULL_BRUSH, this will not produce satisfactory results because edit controls are drawn with SetBkMode(OP...

white spaces in exchange 5.5
Does any one know how to use performance monitor to view how much white space is on an exchange 5.5 server? On Thu, 29 Dec 2005 18:07:02 -0800, Arthur <Arthur @discussions.microsoft.com> wrote: > >Does any one know how to use performance monitor to view how much white >space is on an exchange 5.5 server? > "eseutil /ms" will give a detailed account of the free space. Events 1221 will give you the minimum amount to be recovered. More Info: http://support.microsoft.com/default.aspx?scid=kb;en-us;186291&Product=ech "XADM: Cannot Determine Free Spa...

CEdit PreSubclassWindow Problem
Hi Do anyone know why in derived class of CEdit with PreSubclassWindow that uses a SetWindowText while( m_hWnd is valid for both conditions) it works fine if subclassed with DLG items but if it was created ,it generated Diveded By Zero Access Violation. this brief code makes scenario. thanks in advance. //Header class CMyEdit : public CEdit { public: CMyEdit(){} virtual ~CMyEdit(){} ..... protected: virtual void PreSubclassWindow(); }; //Source void CMyEdit::PreSubclassWindow() { SetWindowText("Preset Text"); } // class CTestDlg : public CDialog { ... CMyEdit m_Edmp; ......

About CEdit
Is there any component like CEdit that accepts only numbers? And how can I get others components in VC6, like listboxes, combos, etc? Thanks in advance. Leonardo Kasperavicius If your using the Dialog Editor, not creating the controls dynamically, the easiest way would be to set the number flag in the properties for the field you want to be numeric only. You get the other controls by selecting them from the control toolbar in the dialog editor as well. If you are creating them dynamically, you would use CListBox, CComboBox, CStatic, CButton, etc... HTH -- ============ Frank Hickman Nobl...

Casio Edifice Chronograph Steel White Mens Watch EF515D-7AVDF
Casio Edifice Chronograph Steel White Mens Watch EF515D-7AVDF Discount Watches Site : http://www.hotwatch.org/ Casio Edifice Chronograph Steel White Mens Watch EF515D-7AVDF Link : http://casio.hotwatch.org/Casio-EF515D-7AVDF.html Casio Edifice Chronograph Steel White Mens Watch EF515D-7AVDF Information : Brand : Casio Watches ( http://casio.hotwatch.org/ ) Gender : Mens Code : Casio-EF515D-7AVDF Item Variations : Movement : Bezel : Case Material : Case Diameter : Dial Color : Crystal : Clasp : Water Resistant : Availability: In StockCasio Edifice Chronograph St...

CEdit Background
When I make CEdit class Read Only, the background turns grey. How can I make it Read Only and have a white background? (Much like the compilation output window in VS Studio). Thanks. Jess You need to handle WM_CTLCOLORSTATIC for a readonly edit control. ----- Ajay Kalra ajaykalra@yahoo.com maybe WM_CTLCOLOREDIT "Ajay Kalra" <ajaykalra@yahoo.com> ??????:1142196362.062801.264450@j33g2000cwa.googlegroups.com... > You need to handle WM_CTLCOLORSTATIC for a readonly edit control. > > ----- > Ajay Kalra > ajaykalra@yahoo.com > WM_CTLCOLOREDIT does not w...

DLL CEdit::Create() Error
I have a class, CMEdit, which inherits from CEdit and when I call my OnCreate function, I simply call CEdit::Create. This class is a private member of another class, CNodeConfig, and when that class is in th emfc application itself, it runs fine. However, when I put it into a dll and call the same thing, I get an assert error in wincore.cpp on line 888 which is: LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd, UINT nMsg, WPARAM wParam = 0, LPARAM lParam = 0) { _AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData(); MSG oldState = pThreadState->m_lastSentMsg; // save f...

How do I print so that the background is red and the print white
I want to print a card on red paper with white printing.. How do I do this? I have seen it done but I don't know the process. Thanks for all help oneelegantone wrote: > I want to print a card on red paper with white printing.. > How do I do this? I have seen it done but I don't know > the process. > > Thanks for all help =========================== You cannot do it unless your printer has white ink...most printers do not. It would use more ink...but what you can do is print a red background with white letters on white paper. Technically the white letters are ...

'SendMessage' is not a member of CEdit, See declaration of 'CEdit'
Can any one tell me what makes my compiler think that. Its making me crazy !! I am using VC++ 6.0. thanks, prakash It's not a member of CEdit but it is a member of it's base class CWnd. "PSN" <prakash437@gmail.com> wrote in message news:1149770896.076143.94070@u72g2000cwu.googlegroups.com... > Can any one tell me what makes my compiler think that. Its making me > crazy !! I am using VC++ 6.0. > > thanks, > prakash > Kurt wrote: > It's not a member of CEdit but it is a member of it's base class CWnd. thats right ... But ist the crite...

Hiding CEdit derived window !
I have a CEdit derived object "m_myedit" on my dialog box and i want to hide or show it dynamically. How can this be done? m_myedit.ShowWindow(SW_HIDE); //hide m_myedit.ShowWindow(SW_SHOWNORMAL); //show Janusz U�ytkownik "Bredal Jensen" <bredal@jensen.dk> napisa� w wiadomo�ci news:OLKDKblmEHA.2880@TK2MSFTNGP14.phx.gbl... > > I have a CEdit derived object "m_myedit" on my dialog box and i want to > hide or show it dynamically. > How can this be done? > > right thanks... "Janusz Grabis" <erfan@poczta.onet.pl> skre...

CEdit SetWindowText rediculously slow
Hi, I have an MFC application, runing on XP. When I do SetWindowText() on an EditControl, it takes >950 ms This seems rediculous, even when reallocation takes place. What can cause this. Is there a faster way to update the text ? Greetings, Rob. "Rob" <Rob@discussions.microsoft.com> wrote in message news:E045587E-6F5D-4E5F-A5DF-85367691CE57@microsoft.com... > > Hi, > I have an MFC application, runing on XP. > When I do SetWindowText() on an EditControl, it takes >950 ms > This seems rediculous, even when reallocation takes place. > > What can c...

OnMouseOver for CEdit and CButton
How may I catch the OnMouseOver event when I have cursor on CEdit and CButton controls ? In control events I can't find this. When I moving curson over CEdit box I want display (in other control) some information about data content in CEdit. How to do it ? MSVS 2005. On 27 Mar 2007 07:29:46 -0700, "Mammoth" <cactusek@gmail.com> wrote: >How may I catch the OnMouseOver event when I have cursor on CEdit and >CButton controls ? In control events I can't find this. >When I moving curson over CEdit box I want display (in other control) >some information about d...

How do I print white objects and/or background in Publisher?
I am tring to print onto a transparent window paper but need the white in the publication to be printed. I've tried to create a new spot colour and registered it, etc. but I can't seem to get this bit to work. Any ideas out there? Thanks. andyphillo wrote: > I am tring to print onto a transparent window paper but > need the white in the publication to be printed. I've > tried to create a new spot colour and registered it, etc. > but I can't seem to get this bit to work. Any ideas out > there? Thanks. ======================================= Very few printers ...

CEdits and CStrings
While going through one of my projects and applying variable names to some of the controls I generally found that doing so for controls like buttons usually defaulted to a control type of CButton or such. But with CEdits it would default to a value type of CString. Is this some sort of shortcut to accessing the text within a CEdit control rather than having to extract the text before using it? Or is this some sort of behavior of the compiling environment that I just need to accept? Thanks, Lilith The default *control* for it is CEdit, CString is the default variable type, which is added ...

CEdit and \n
I have a CEdit control that loads a text file with multiple lines. Instead of the text box showing a new line it shows the little black box. I set the multi-line property to true, why is this behavior happening Thank "Mark" <anonymous@discussions.microsoft.com> wrote in message news:C41E31D2-7ACD-463D-B0D3-A16A128B053D@microsoft.com... > I have a CEdit control that loads a text file with multiple lines. Instead of the text box showing a new line it shows the little black box. I set the multi-line property to true, why is this behavior happening? > Thanks I think the ed...

where to create CEdit again
I created a CEdit control in OnInitUpdate, but the postion is fixed. I want it to be repositioned again when CView is resized. What is the right place to create this control again? I tried onDraw, the control is blinking all the times. thanks pat/ simple use CView::OnSize(int cx,int cy) if(GetSafeHwnd()) { if( myEdit.GetSafeHwnd()) myEdit.MoveWindow(CRect(0,0,cx,cy)); } } reg -Jibesh ------------------------------------------------------------------------- FIGHT BACK AGAINST SPAM! Download Spam Inspector, the Award Winning Anti-Spam Filter http://mail.giantcompany.com &...

is it a bug of CEdit?
I use resouce edit to define a CEdit control which only accept digit number. I found,when I input char to the edit by typing ,it works well,only accept digit. but I still can use ctrl + c to paste non-digit char into it. to work around this problem,I check the input every time the content of the cedit vary which induce an event to report the change >I found,when I input char to the edit by typing ,it works well,only accept >digit. >but I still can use ctrl + c to paste non-digit char into it. It is a documented quirk! ;) See ES_NUMBER here: http://msdn.microsoft.com/librar...

Copy/Paste in CMyEdit that inherits from CEdit
Hi everyone, I created a new class CMyEdit that inherits from CEdit. Then I defined an edit control in my dialog to this type. So basically the only thing I changed is using the class CMyEdit instead of CEdit for the edit control. The problem is that when I run the program, I can't copy/paste anymore in the edit control using the keyboard (Ctrl+C and Ctrl+V). I have to do it only with the mouse. Note that CMyEdit does not define any new function or override or overload any function from CEdit. I have just created it with the Add Class Wizard and tested my code. What should I do t...

CEdit::SetSel() did not work
Hi, I have a CEdit control which I called its method SetSel (0, -1) but no text is selected. My CEdit control is read only. Am I missing something? Thanks a lot, Mike Try SetFocus() before calling SetSel(). Something like YourEditControl.SetFocus(); YourEditControl.SetSel(0,-1); -- Cheers Check Abdoul [VC++ MVP] ----------------------------------- "Mike" <anonymous@discussions.microsoft.com> wrote in message news:143b01c4cc2f$3d758e20$a501280a@phx.gbl... > Hi, > > I have a CEdit control which I called its method SetSel > (0, -1) but ...