recreate a window

a CComboBox and CQControl derived control shall recreate itself, if
the styles given in resource not match the style required for toe
control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
to correctly modify this style with ModifyStyle(), the recreation is
called and works.

____________________________________________
//-----------------------------------------------------------------------
// recreate the underlying hwnd to match required styles
bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
{
	CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
	ASSERT(pWnd != NULL);
	ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
	if (pWnd == NULL)
		return false;

	CRect rc;
	HWND hParent = GetParent(m_hwnd);

	// get position and size of current window
	GetWindowRect(m_hwnd, &rc);

	// following fn's need width and size, we recycle rc
	rc.right  = rc.Width();
	rc.bottom = rc.Height();

	// translate into parents coordinates
	ScreenToClient(hParent, &rc.TopLeft());

	// let derived class modify rc
	OnCreationRect(rc);

	// create a new window at current windows coordinates
	HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", dwStyle,
		rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
		::AfxGetInstanceHandle(), NULL);

	// destroy old window and attach new one
	DestroyWindow(pWnd->Detach());
	pWnd->Attach(hNew);
	m_hwnd = hNew;
	return true;
}

____________________________________________

however, when the dialog is closed, the line 991 (marked "/******/"
in Wincore.cpp asserts:
____________________________________________
BOOL CWnd::DestroyWindow()
{
	if (m_hWnd == NULL)
		return FALSE;

	CHandleMap* pMap = afxMapHWND();
	ASSERT(pMap != NULL);
	CWnd* pWnd = (CWnd*)pMap->LookupPermanent(m_hWnd);
#ifdef _DEBUG
	HWND hWndOrig = m_hWnd;
#endif

#ifdef _AFX_NO_OCC_SUPPORT
	BOOL bResult = ::DestroyWindow(m_hWnd);
#else //_AFX_NO_OCC_SUPPORT
	BOOL bResult;
	if (m_pCtrlSite == NULL)
		bResult = ::DestroyWindow(m_hWnd);
	else
		bResult = m_pCtrlSite->DestroyControl();
#endif //_AFX_NO_OCC_SUPPORT

	// Note that 'this' may have been deleted at this point,
	//  (but only if pWnd != NULL)
	if (pWnd != NULL)
	{
		// Should have been detached by OnNcDestroy
#ifdef _DEBUG
		ASSERT(pMap->LookupPermanent(hWndOrig) == NULL); /******/
#endif
	}
	else
	{
#ifdef _DEBUG
		ASSERT(m_hWnd == hWndOrig);
#endif
		// Detach after DestroyWindow called just in case
		Detach();
	}
	return bResult;
}
____________________________________________


As i definitively Detached() the hwnd, i'd apprechiate any
enlightenment...

~.rhavin;)
0
clqrq (258)
11/10/2008 4:09:56 PM
vc.mfc 33608 articles. 0 followers. Follow

12 Replies
927 Views

Similar Articles

[PageSpeed] 19

See below...
On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <clqrq@yahoo.de> wrote:

>a CComboBox and CQControl derived control shall recreate itself, if
>the styles given in resource not match the style required for toe
>control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
>to correctly modify this style with ModifyStyle(), the recreation is
>called and works.
****
The error is that you did not do this at design time.  Essentially, I treat the failure to
have the wrong styles as an error.  Not sure why you are bothering to work around a bug
that shouldn't exist.  If this happens, you ASSERT and then fix the dialog at design time,
and omit ALL the code below.

CComboBox is not *supposed* to be able to modify this style after the control is created,
so it is not "unable to correctly modify this style" because it was never defined that
this is even possible.
****
>
>____________________________________________
>//-----------------------------------------------------------------------
>// recreate the underlying hwnd to match required styles
>bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
>{
>	CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
****
This is unnecessary; 'this' is already the CWnd *.  So there is no need for the above
line.
****
>	ASSERT(pWnd != NULL);
>	ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
>	if (pWnd == NULL)
>		return false;
****
The above statements are meaningless.  You already have 'this' or you wouldn't be here. It
doesn't matter about what map it is in; you shouldn't care, either.

Note that I use this technique rather often to create a control in a space formerly
occupied by a CStatic, so I'm changing the entire control type.  This code is FAR too
complicated for such a simple task.
****
>
>	CRect rc;
>	HWND hParent = GetParent(m_hwnd);		// [1]
****
CWnd * parent = GetParent();
****
>
>	// get position and size of current window
>	GetWindowRect(m_hwnd, &rc);                                       // [2]
****
I'm surprised this even compiles.  There is no need to use the raw HWND.  You could just
have written
	GetWindowRect(&rc);
and get everything you need.
>
>	// following fn's need width and size, we recycle rc
>	rc.right  = rc.Width();                                                          // [3]
>	rc.bottom = rc.Height();                                                    // [4]
***
This code is incorrect.  You must not set the right and bottom in this fashion, because
you are working with the window rect, and the width and height are independent of the
coordinate system.  Lose the two assignments above.
>
>	// translate into parents coordinates
>	ScreenToClient(hParent, &rc.TopLeft());                        // [5]
****
Why are you not doing something as simple as
                CRect rc;
                GetWindowRect(&rc);
                GetParent()->ScreenToClient(&rc);
this is all you need.  You have a complex and convoluted solution to a simple problem.
Just translating the top/left coordinate makes no sense, because it will produce a window
that has the wrong size.

You have five overly complicated lines doing what two trivial lines will accomplish. 
****
>
>	// let derived class modify rc
>	OnCreationRect(rc);
****
I have no idea what this does because there is no handler called OnCreationRect and you
have not given the code for this, but there's nothing I know that needs to be done to this
rectangle once you have it.
****
>
>	// create a new window at current windows coordinates
>	HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", dwStyle,
>		rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
>		::AfxGetInstanceHandle(), NULL);
****
Why are you using the raw CreateWindowEx call?  You can do this trivially in MFC:

	CWnd temp;
        	temp.CreateEx(dwStyleEx, QGetClassName(), _T(""), dwStyle, rc, 
			GetDlgCtrlId(), parent);
Note how simple this is.  For that matter, does CQControl have a Create method that would
be better?

I have no idea why you have chosen to change the control ID by setting it to 0; this kills
off all your handlers in the parent window.  For a brief moment you will have two controls
with the same ID, but this will be changed momentarily, and causes no harm.

But what you didn't do was make sure it is in the right place in the Z-order
	temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
	DestroyWindow();
	Attach(temp.Detach());

All this use of raw API and HWNDs is unneccessay. 
*****

>
>	// destroy old window and attach new one
>	DestroyWindow(pWnd->Detach());
>	pWnd->Attach(hNew);
>	m_hwnd = hNew;
****
Get rid of all the above lines.

The convoluted nature of what you are doing is probably what leads to the assertion
failure.  I wouldn't even try to debug this code, I would rewrite it as indicated.  Then,
and only then, if there is still a bug, would I worry about it.
****
>	return true;
>}
>
>____________________________________________
>
>however, when the dialog is closed, the line 991 (marked "/******/"
>in Wincore.cpp asserts:
>____________________________________________
>BOOL CWnd::DestroyWindow()
>{
>	if (m_hWnd == NULL)
>		return FALSE;
>
>	CHandleMap* pMap = afxMapHWND();
>	ASSERT(pMap != NULL);
>	CWnd* pWnd = (CWnd*)pMap->LookupPermanent(m_hWnd);
>#ifdef _DEBUG
>	HWND hWndOrig = m_hWnd;
>#endif
>
>#ifdef _AFX_NO_OCC_SUPPORT
>	BOOL bResult = ::DestroyWindow(m_hWnd);
>#else //_AFX_NO_OCC_SUPPORT
>	BOOL bResult;
>	if (m_pCtrlSite == NULL)
>		bResult = ::DestroyWindow(m_hWnd);
>	else
>		bResult = m_pCtrlSite->DestroyControl();
>#endif //_AFX_NO_OCC_SUPPORT
>
>	// Note that 'this' may have been deleted at this point,
>	//  (but only if pWnd != NULL)
>	if (pWnd != NULL)
>	{
>		// Should have been detached by OnNcDestroy
>#ifdef _DEBUG
>		ASSERT(pMap->LookupPermanent(hWndOrig) == NULL); /******/
>#endif
>	}
>	else
>	{
>#ifdef _DEBUG
>		ASSERT(m_hWnd == hWndOrig);
>#endif
>		// Detach after DestroyWindow called just in case
>		Detach();
>	}
>	return bResult;
>}
>____________________________________________
>
>
>As i definitively Detached() the hwnd, i'd apprechiate any
>enlightenment...
>
>~.rhavin;)
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15972)
11/10/2008 5:59:59 PM
On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
> See below...
>
> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@yahoo.=
de> wrote:
> >a CComboBox and CQControl derived control shall recreate itself, if
> >the styles given in resource not match the style required for toe
> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
> >to correctly modify this style with ModifyStyle(), the recreation is
> >called and works.
>
> ****
> The error is that you did not do this at design time. =A0Essentially, I t=
reat the failure to
> have the wrong styles as an error. =A0Not sure why you are bothering to w=
ork around a bug
> that shouldn't exist. =A0If this happens, you ASSERT and then fix the dia=
log at design time,
> and omit ALL the code below.
> CComboBox is not *supposed* to be able to modify this style after the con=
trol is created,
> so it is not "unable to correctly modify this style" because it was never=
 defined that
> this is even possible.
> ****

thats why i recreate it.

>
> >____________________________________________
> >//----------------------------------------------------------------------=
-
> >// recreate the underlying hwnd to match required styles
> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
> >{
> > =A0 =A0CWnd* pWnd =3D CWnd::FromHandlePermanent(m_hwnd);
>
> ****
> This is unnecessary; 'this' is already the CWnd *. =A0So there is no need=
 for the above
> line.

no it is not. 'this' is a CQControl that has no CWnd as baseclass! for
example, the
CQComboBox is a public CComboBox, public CQControl.

> ****> =A0 =A0ASSERT(pWnd !=3D NULL);
> > =A0 =A0ASSERT(pWnd =3D=3D CWnd::FromHandle(m_hwnd));
> > =A0 =A0if (pWnd =3D=3D NULL)
> > =A0 =A0 =A0 =A0 =A0 =A0return false;
>
> ****
> The above statements are meaningless. =A0You already have 'this' or you w=
ouldn't be here. It
> doesn't matter about what map it is in; you shouldn't care, either.

see above.

> Note that I use this technique rather often to create a control in a spac=
e formerly
> occupied by a CStatic, so I'm changing the entire control type. =A0This c=
ode is FAR too
> complicated for such a simple task.
> ****

a static in Dialog-Editor would not look like a combobox.

> > =A0 =A0CRect rc;
> > =A0 =A0HWND hParent =3D GetParent(m_hwnd); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
// [1]
>
> ****
> CWnd * parent =3D GetParent();
> ****

wrong. see above.

>
> > =A0 =A0// get position and size of current window
> > =A0 =A0GetWindowRect(m_hwnd, &rc); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // [2]
>
> ****
> I'm surprised this even compiles. =A0There is no need to use the raw HWND=
.. =A0You could just
> have written
> =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> and get everything you need.

see above;-)

>
> > =A0 =A0// following fn's need width and size, we recycle rc
> > =A0 =A0rc.right =A0=3D rc.Width(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0// [3]
> > =A0 =A0rc.bottom =3D rc.Height(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// [4]
>
> ***
> This code is incorrect. =A0You must not set the right and bottom in this =
fashion, because
> you are working with the window rect, and the width and height are indepe=
ndent of the
> coordinate system. =A0Lose the two assignments above.
>
> > =A0 =A0// translate into parents coordinates
> > =A0 =A0ScreenToClient(hParent, &rc.TopLeft()); =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0// [5]
>
> ****
> Why are you not doing something as simple as
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CRect rc;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetParent()->ScreenToClient(&rc);
> this is all you need. =A0You have a complex and convoluted solution to a =
simple problem.
> Just translating the top/left coordinate makes no sense, because it will =
produce a window
> that has the wrong size.

no. everything works pretty well. i you insist, one could of course
define a struct RECT_ that has let, top, width and height members, but
apart from that, my way is completely ok.

>
> You have five overly complicated lines doing what two trivial lines will =
accomplish.
> ****
>
> > =A0 =A0// let derived class modify rc
> > =A0 =A0OnCreationRect(rc);
>
> ****
> I have no idea what this does because there is no handler called OnCreati=
onRect and you
> have not given the code for this, but there's nothing I know that needs t=
o be done to this
> rectangle once you have it.
> ****

in this case, the derived class uses this virtual as following:

void CQComboBox::OnCreationRect(RECT& rc)
{
	RECT rcDropped;
	GetDroppedControlRect(&rcDropped);
	rc.bottom =3D rcDropped.bottom - rcDropped.top;
}


>
> > =A0 =A0// create a new window at current windows coordinates
> > =A0 =A0HWND hNew =3D CreateWindowEx(dwStyleEx, QGetClassName(), "", dwS=
tyle,
> > =A0 =A0 =A0 =A0 =A0 =A0rc.left, rc.top, rc.right, rc.bottom, hParent, 0=
,
> > =A0 =A0 =A0 =A0 =A0 =A0::AfxGetInstanceHandle(), NULL);
>
> ****
> Why are you using the raw CreateWindowEx call? =A0You can do this trivial=
ly in MFC:
>
> =A0 =A0 =A0 =A0 CWnd temp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 temp.CreateEx(dwStyleEx, QGetClassName(),=
 _T(""), dwStyle, rc,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetDlgCtrlId(), parent);
> Note how simple this is. =A0For that matter, does CQControl have a Create=
 method that would
> be better?
>
> I have no idea why you have chosen to change the control ID by setting it=
 to 0; this kills
> off all your handlers in the parent window. =A0For a brief moment you wil=
l have two controls
> with the same ID, but this will be changed momentarily, and causes no har=
m.

oh, i thought it was hMenu.

>
> But what you didn't do was make sure it is in the right place in the Z-or=
der
> =A0 =A0 =A0 =A0 temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSI=
ZE);
> =A0 =A0 =A0 =A0 DestroyWindow();
> =A0 =A0 =A0 =A0 Attach(temp.Detach());
>
> All this use of raw API and HWNDs is unneccessay.
> *****
>
>
>
> > =A0 =A0// destroy old window and attach new one
> > =A0 =A0DestroyWindow(pWnd->Detach());
> > =A0 =A0pWnd->Attach(hNew);
> > =A0 =A0m_hwnd =3D hNew;
>
> ****
> Get rid of all the above lines.
>
> The convoluted nature of what you are doing is probably what leads to the=
 assertion
> failure. =A0I wouldn't even try to debug this code, I would rewrite it as=
 indicated. =A0Then,
> and only then, if there is still a bug, would I worry about it.
> ****
>
> > =A0 =A0return true;
> >}
>
> >____________________________________________
>
> >however, when the dialog is closed, the line 991 (marked "/******/"
> >in Wincore.cpp asserts:
> >____________________________________________
> >BOOL CWnd::DestroyWindow()
> >{
> > =A0 =A0if (m_hWnd =3D=3D NULL)
> > =A0 =A0 =A0 =A0 =A0 =A0return FALSE;
>
> > =A0 =A0CHandleMap* pMap =3D afxMapHWND();
> > =A0 =A0ASSERT(pMap !=3D NULL);
> > =A0 =A0CWnd* pWnd =3D (CWnd*)pMap->LookupPermanent(m_hWnd);
> >#ifdef _DEBUG
> > =A0 =A0HWND hWndOrig =3D m_hWnd;
> >#endif
>
> >#ifdef _AFX_NO_OCC_SUPPORT
> > =A0 =A0BOOL bResult =3D ::DestroyWindow(m_hWnd);
> >#else //_AFX_NO_OCC_SUPPORT
> > =A0 =A0BOOL bResult;
> > =A0 =A0if (m_pCtrlSite =3D=3D NULL)
> > =A0 =A0 =A0 =A0 =A0 =A0bResult =3D ::DestroyWindow(m_hWnd);
> > =A0 =A0else
> > =A0 =A0 =A0 =A0 =A0 =A0bResult =3D m_pCtrlSite->DestroyControl();
> >#endif //_AFX_NO_OCC_SUPPORT
>
> > =A0 =A0// Note that 'this' may have been deleted at this point,
> > =A0 =A0// =A0(but only if pWnd !=3D NULL)
> > =A0 =A0if (pWnd !=3D NULL)
> > =A0 =A0{
> > =A0 =A0 =A0 =A0 =A0 =A0// Should have been detached by OnNcDestroy
> >#ifdef _DEBUG
> > =A0 =A0 =A0 =A0 =A0 =A0ASSERT(pMap->LookupPermanent(hWndOrig) =3D=3D NU=
LL); /******/
> >#endif
> > =A0 =A0}
> > =A0 =A0else
> > =A0 =A0{
> >#ifdef _DEBUG
> > =A0 =A0 =A0 =A0 =A0 =A0ASSERT(m_hWnd =3D=3D hWndOrig);
> >#endif
> > =A0 =A0 =A0 =A0 =A0 =A0// Detach after DestroyWindow called just in cas=
e
> > =A0 =A0 =A0 =A0 =A0 =A0Detach();
> > =A0 =A0}
> > =A0 =A0return bResult;
> >}
> >____________________________________________
>
> >As i definitively Detached() the hwnd, i'd apprechiate any
> >enlightenment...
>
> >~.rhavin;)
>
> Joseph M. Newcomer [MVP]
> email: newco...@flounder.com
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm

0
clqrq (258)
11/10/2008 6:26:29 PM
See below...
On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" <clqrq@yahoo.de> wrote:

>On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> See below...
>>
>> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >a CComboBox and CQControl derived control shall recreate itself, if
>> >the styles given in resource not match the style required for toe
>> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
>> >to correctly modify this style with ModifyStyle(), the recreation is
>> >called and works.
>>
>> ****
>> The error is that you did not do this at design time. �Essentially, I treat the failure to
>> have the wrong styles as an error. �Not sure why you are bothering to work around a bug
>> that shouldn't exist. �If this happens, you ASSERT and then fix the dialog at design time,
>> and omit ALL the code below.
>> CComboBox is not *supposed* to be able to modify this style after the control is created,
>> so it is not "unable to correctly modify this style" because it was never defined that
>> this is even possible.
>> ****
>
>thats why i recreate it.
***
My point is, a program which has one of these which is NOT defined as CBS_OWNERDRAWFIXED
is an erroneous program, so you fix it in the dialog template once, and never again worry
about it.
****
>
>>
>> >____________________________________________
>> >//-----------------------------------------------------------------------
>> >// recreate the underlying hwnd to match required styles
>> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
>> >{
>> > � �CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
>>
>> ****
>> This is unnecessary; 'this' is already the CWnd *. �So there is no need for the above
>> line.
>
>no it is not. 'this' is a CQControl that has no CWnd as baseclass! for
>example, the
>CQComboBox is a public CComboBox, public CQControl.
****
That's a different question than the one you asked.  You did not specify that you are
using multiple inheritance.

But in that case, FromHandle is sufficient.
****
>
>> ****> � �ASSERT(pWnd != NULL);
>> > � �ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
>> > � �if (pWnd == NULL)
>> > � � � � � �return false;
>>
>> ****
>> The above statements are meaningless. �You already have 'this' or you wouldn't be here. It
>> doesn't matter about what map it is in; you shouldn't care, either.
>
>see above.
****
You have to provide *all* relevant information in order to get a correct answer
****
>
>> Note that I use this technique rather often to create a control in a space formerly
>> occupied by a CStatic, so I'm changing the entire control type. �This code is FAR too
>> complicated for such a simple task.
>> ****
>
>a static in Dialog-Editor would not look like a combobox.
>
>> > � �CRect rc;
>> > � �HWND hParent = GetParent(m_hwnd); � � � � � � � // [1]
>>
>> ****
>> CWnd * parent = GetParent();
>> ****
>
>wrong. see above.
****
If you use multiple inheritance, a previously unstated case, then yes.  But you can't ask
a question without giving all relevant information and expect to get a relevant answer
****
>
>>
>> > � �// get position and size of current window
>> > � �GetWindowRect(m_hwnd, &rc); � � � � � � � � � � � � � � � � � � � // [2]
>>
>> ****
>> I'm surprised this even compiles. �There is no need to use the raw HWND. �You could just
>> have written
>> � � � � GetWindowRect(&rc);
>> and get everything you need.
>
>see above;-)
>
>>
>> > � �// following fn's need width and size, we recycle rc
>> > � �rc.right �= rc.Width(); � � � � � � � � � � � � � � � � � � � � � � � � � � � � �// [3]
>> > � �rc.bottom = rc.Height(); � � � � � � � � � � � � � � � � � � � � � � � � � �// [4]
>>
>> ***
>> This code is incorrect. �You must not set the right and bottom in this fashion, because
>> you are working with the window rect, and the width and height are independent of the
>> coordinate system. �Lose the two assignments above.
>>
>> > � �// translate into parents coordinates
>> > � �ScreenToClient(hParent, &rc.TopLeft()); � � � � � � � � � � � �// [5]
>>
>> ****
>> Why are you not doing something as simple as
>> � � � � � � � � CRect rc;
>> � � � � � � � � GetWindowRect(&rc);
>> � � � � � � � � GetParent()->ScreenToClient(&rc);
>> this is all you need. �You have a complex and convoluted solution to a simple problem.
>> Just translating the top/left coordinate makes no sense, because it will produce a window
>> that has the wrong size.
>
>no. everything works pretty well. i you insist, one could of course
>define a struct RECT_ that has let, top, width and height members, but
>apart from that, my way is completely ok.
****
Why do you need to define a new structure?  You can just do
	CRect rc;
 	::GetWindowRect(m_hWnd, &rc);
	::ScreenToClient(parent, &rc);
where, now that I know you are using multiple inheritance, is still simpler than the
complex code you wrote.  And by setting the right and bottom to the Width() and Height(),
BEFORE transforming the top and left, you still get the wrong size.
****
>
>>
>> You have five overly complicated lines doing what two trivial lines will accomplish.
>> ****
>>
>> > � �// let derived class modify rc
>> > � �OnCreationRect(rc);
>>
>> ****
>> I have no idea what this does because there is no handler called OnCreationRect and you
>> have not given the code for this, but there's nothing I know that needs to be done to this
>> rectangle once you have it.
>> ****
>
>in this case, the derived class uses this virtual as following:
>
>void CQComboBox::OnCreationRect(RECT& rc)
>{
>	RECT rcDropped;
>	GetDroppedControlRect(&rcDropped);
>	rc.bottom = rcDropped.bottom - rcDropped.top;
>}
****
Using the 'On' prefix, which is used for handlers, is confusing.  Calling it something
meaningful like ComputeDroppedRect might have made it less ambiguous as to what was going
on.
****
>
>
>>
>> > � �// create a new window at current windows coordinates
>> > � �HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", dwStyle,
>> > � � � � � �rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
>> > � � � � � �::AfxGetInstanceHandle(), NULL);
>>
>> ****
>> Why are you using the raw CreateWindowEx call? �You can do this trivially in MFC:
>>
>> � � � � CWnd temp;
>> � � � � � � � � temp.CreateEx(dwStyleEx, QGetClassName(), _T(""), dwStyle, rc,
>> � � � � � � � � � � � � GetDlgCtrlId(), parent);
>> Note how simple this is. �For that matter, does CQControl have a Create method that would
>> be better?
>>
>> I have no idea why you have chosen to change the control ID by setting it to 0; this kills
>> off all your handlers in the parent window. �For a brief moment you will have two controls
>> with the same ID, but this will be changed momentarily, and causes no harm.
>
>oh, i thought it was hMenu.
****
Note that it is specified as being the hMenu for a top-level window and the control ID for
a child window.  From the documentation:

"For a child window, hMenu specifies the child-window identifer, an integer value..."

It will have to be cast to an HMENU to satisfy the compiler.
				joe
****
>
>>
>> But what you didn't do was make sure it is in the right place in the Z-order
>> � � � � temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
>> � � � � DestroyWindow();
>> � � � � Attach(temp.Detach());
>>
>> All this use of raw API and HWNDs is unneccessay.
>> *****
>>
>>
>>
>> > � �// destroy old window and attach new one
>> > � �DestroyWindow(pWnd->Detach());
>> > � �pWnd->Attach(hNew);
>> > � �m_hwnd = hNew;
>>
>> ****
>> Get rid of all the above lines.
>>
>> The convoluted nature of what you are doing is probably what leads to the assertion
>> failure. �I wouldn't even try to debug this code, I would rewrite it as indicated. �Then,
>> and only then, if there is still a bug, would I worry about it.
****
Since MFC does not normally support multiple inheritance, there can be some confusing side
effects here that may account for it.  What is the type of the object displayed by the
debugger?  

Is there a reason you chose to use multiple inheritance over direct inheritance?  You are
working in unsupported areas here.
					joe
****
>> ****
>>
>> > � �return true;
>> >}
>>
>> >____________________________________________
>>
>> >however, when the dialog is closed, the line 991 (marked "/******/"
>> >in Wincore.cpp asserts:
>> >____________________________________________
>> >BOOL CWnd::DestroyWindow()
>> >{
>> > � �if (m_hWnd == NULL)
>> > � � � � � �return FALSE;
>>
>> > � �CHandleMap* pMap = afxMapHWND();
>> > � �ASSERT(pMap != NULL);
>> > � �CWnd* pWnd = (CWnd*)pMap->LookupPermanent(m_hWnd);
>> >#ifdef _DEBUG
>> > � �HWND hWndOrig = m_hWnd;
>> >#endif
>>
>> >#ifdef _AFX_NO_OCC_SUPPORT
>> > � �BOOL bResult = ::DestroyWindow(m_hWnd);
>> >#else //_AFX_NO_OCC_SUPPORT
>> > � �BOOL bResult;
>> > � �if (m_pCtrlSite == NULL)
>> > � � � � � �bResult = ::DestroyWindow(m_hWnd);
>> > � �else
>> > � � � � � �bResult = m_pCtrlSite->DestroyControl();
>> >#endif //_AFX_NO_OCC_SUPPORT
>>
>> > � �// Note that 'this' may have been deleted at this point,
>> > � �// �(but only if pWnd != NULL)
>> > � �if (pWnd != NULL)
>> > � �{
>> > � � � � � �// Should have been detached by OnNcDestroy
>> >#ifdef _DEBUG
>> > � � � � � �ASSERT(pMap->LookupPermanent(hWndOrig) == NULL); /******/
>> >#endif
>> > � �}
>> > � �else
>> > � �{
>> >#ifdef _DEBUG
>> > � � � � � �ASSERT(m_hWnd == hWndOrig);
>> >#endif
>> > � � � � � �// Detach after DestroyWindow called just in case
>> > � � � � � �Detach();
>> > � �}
>> > � �return bResult;
>> >}
>> >____________________________________________
>>
>> >As i definitively Detached() the hwnd, i'd apprechiate any
>> >enlightenment...
>>
>> >~.rhavin;)
>>
>> Joseph M. Newcomer [MVP]
>> email: newco...@flounder.com
>> Web:http://www.flounder.com
>> MVP Tips:http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15972)
11/10/2008 7:43:37 PM
On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
> See below...
> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" <cl...@yahoo.=
de> wrote:
> >On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
> >> See below...
>
> >> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@yah=
oo.de> wrote:
> >> >a CComboBox and CQControl derived control shall recreate itself, if
> >> >the styles given in resource not match the style required for toe
> >> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unabl=
e
> >> >to correctly modify this style with ModifyStyle(), the recreation is
> >> >called and works.
>
> >> ****
> >> The error is that you did not do this at design time. =A0Essentially, =
I treat the failure to
> >> have the wrong styles as an error. =A0Not sure why you are bothering t=
o work around a bug
> >> that shouldn't exist. =A0If this happens, you ASSERT and then fix the =
dialog at design time,
> >> and omit ALL the code below.
> >> CComboBox is not *supposed* to be able to modify this style after the =
control is created,
> >> so it is not "unable to correctly modify this style" because it was ne=
ver defined that
> >> this is even possible.
> >> ****
>
> >thats why i recreate it.
>
> ***
> My point is, a program which has one of these which is NOT defined as CBS=
_OWNERDRAWFIXED
> is an erroneous program, so you fix it in the dialog template once, and n=
ever again worry
> about it.
> ****

if there's no way to let my code correct the error, i'd assert. but i
thought to use this flags myself, e.g. recreate a control with the
appropriate windowsflags needed for the control, and use the user-
defined flags for my own implementation (in this case, calling a user-
defined drawing routine instead of my own default drawing routine.)

>
> >> >____________________________________________
> >> >//-------------------------------------------------------------------=
----
> >> >// recreate the underlying hwnd to match required styles
> >> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
> >> >{
> >> > =A0 =A0CWnd* pWnd =3D CWnd::FromHandlePermanent(m_hwnd);
>
> >> ****
> >> This is unnecessary; 'this' is already the CWnd *. =A0So there is no n=
eed for the above
> >> line.
>
> >no it is not. 'this' is a CQControl that has no CWnd as baseclass! for
> >example, the
> >CQComboBox is a public CComboBox, public CQControl.
>
> ****
> That's a different question than the one you asked. =A0You did not specif=
y that you are
> using multiple inheritance.

i did'nt say i'm not using it;-)  But you're right, assuming direct(?)
inheritance is the default.
>
> But in that case, FromHandle is sufficient.
> ****

i just wanted to be shure.

>
> >> ****> =A0 =A0ASSERT(pWnd !=3D NULL);
> >> > =A0 =A0ASSERT(pWnd =3D=3D CWnd::FromHandle(m_hwnd));
> >> > =A0 =A0if (pWnd =3D=3D NULL)
> >> > =A0 =A0 =A0 =A0 =A0 =A0return false;
>
> >> ****
> >> The above statements are meaningless. =A0You already have 'this' or yo=
u wouldn't be here. It
> >> doesn't matter about what map it is in; you shouldn't care, either.
>
> >see above.
>
> ****
> You have to provide *all* relevant information in order to get a correct =
answer
> ****
>
> >> Note that I use this technique rather often to create a control in a s=
pace formerly
> >> occupied by a CStatic, so I'm changing the entire control type. =A0Thi=
s code is FAR too
> >> complicated for such a simple task.
> >> ****
>
> >a static in Dialog-Editor would not look like a combobox.
>
> >> > =A0 =A0CRect rc;
> >> > =A0 =A0HWND hParent =3D GetParent(m_hwnd); =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 // [1]
>
> >> ****
> >> CWnd * parent =3D GetParent();
> >> ****
>
> >wrong. see above.
>
> ****
> If you use multiple inheritance, a previously unstated case, then yes. =
=A0But you can't ask
> a question without giving all relevant information and expect to get a re=
levant answer
> ****
> >> > =A0 =A0// get position and size of current window
> >> > =A0 =A0GetWindowRect(m_hwnd, &rc); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // [2]
>
> >> ****
> >> I'm surprised this even compiles. =A0There is no need to use the raw H=
WND. =A0You could just
> >> have written
> >> =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> >> and get everything you need.
>
> >see above;-)
>
> >> > =A0 =A0// following fn's need width and size, we recycle rc
> >> > =A0 =A0rc.right =A0=3D rc.Width(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0// [3]
> >> > =A0 =A0rc.bottom =3D rc.Height(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// [=
4]
>
> >> ***
> >> This code is incorrect. =A0You must not set the right and bottom in th=
is fashion, because
> >> you are working with the window rect, and the width and height are ind=
ependent of the
> >> coordinate system. =A0Lose the two assignments above.
>
> >> > =A0 =A0// translate into parents coordinates
> >> > =A0 =A0ScreenToClient(hParent, &rc.TopLeft()); =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0// [5]
>
> >> ****
> >> Why are you not doing something as simple as
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CRect rc;
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetParent()->ScreenToClient(&rc);
> >> this is all you need. =A0You have a complex and convoluted solution to=
 a simple problem.
> >> Just translating the top/left coordinate makes no sense, because it wi=
ll produce a window
> >> that has the wrong size.
>
> >no. everything works pretty well. i you insist, one could of course
> >define a struct RECT_ that has let, top, width and height members, but
> >apart from that, my way is completely ok.
>
> ****
> Why do you need to define a new structure? =A0You can just do
> =A0 =A0 =A0 =A0 CRect rc;
> =A0 =A0 =A0 =A0 ::GetWindowRect(m_hWnd, &rc);
> =A0 =A0 =A0 =A0 ::ScreenToClient(parent, &rc);
> where, now that I know you are using multiple inheritance, is still simpl=
er than the
> complex code you wrote. =A0And by setting the right and bottom to the Wid=
th() and Height(),
> BEFORE transforming the top and left, you still get the wrong size.
> ****

=E4hm, no..  both rects are in pixel.

>
> >> You have five overly complicated lines doing what two trivial lines wi=
ll accomplish.
> >> ****
>
> >> > =A0 =A0// let derived class modify rc
> >> > =A0 =A0OnCreationRect(rc);
>
> >> ****
> >> I have no idea what this does because there is no handler called OnCre=
ationRect and you
> >> have not given the code for this, but there's nothing I know that need=
s to be done to this
> >> rectangle once you have it.
> >> ****
>
> >in this case, the derived class uses this virtual as following:
>
> >void CQComboBox::OnCreationRect(RECT& rc)
> >{
> > =A0 =A0RECT rcDropped;
> > =A0 =A0GetDroppedControlRect(&rcDropped);
> > =A0 =A0rc.bottom =3D rcDropped.bottom - rcDropped.top;
> >}
>
> ****
> Using the 'On' prefix, which is used for handlers, is confusing. =A0Calli=
ng it something
> meaningful like ComputeDroppedRect might have made it less ambiguous as t=
o what was going
> on.
> ****
>
> >> > =A0 =A0// create a new window at current windows coordinates
> >> > =A0 =A0HWND hNew =3D CreateWindowEx(dwStyleEx, QGetClassName(), "", =
dwStyle,
> >> > =A0 =A0 =A0 =A0 =A0 =A0rc.left, rc.top, rc.right, rc.bottom, hParent=
, 0,
> >> > =A0 =A0 =A0 =A0 =A0 =A0::AfxGetInstanceHandle(), NULL);
>
> >> ****
> >> Why are you using the raw CreateWindowEx call? =A0You can do this triv=
ially in MFC:
>
> >> =A0 =A0 =A0 =A0 CWnd temp;
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 temp.CreateEx(dwStyleEx, QGetClassName=
(), _T(""), dwStyle, rc,
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetDlgCtrlId(), parent=
);
> >> Note how simple this is. =A0For that matter, does CQControl have a Cre=
ate method that would
> >> be better?
>
> >> I have no idea why you have chosen to change the control ID by setting=
 it to 0; this kills
> >> off all your handlers in the parent window. =A0For a brief moment you =
will have two controls
> >> with the same ID, but this will be changed momentarily, and causes no =
harm.
>
> >oh, i thought it was hMenu.
>
> ****
> Note that it is specified as being the hMenu for a top-level window and t=
he control ID for
> a child window. =A0From the documentation:
>
> "For a child window, hMenu specifies the child-window identifer, an integ=
er value..."
>
> It will have to be cast to an HMENU to satisfy the compiler.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joe
> ****
>
>
>
> >> But what you didn't do was make sure it is in the right place in the Z=
-order
> >> =A0 =A0 =A0 =A0 temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_N=
OSIZE);
> >> =A0 =A0 =A0 =A0 DestroyWindow();
> >> =A0 =A0 =A0 =A0 Attach(temp.Detach());
>
> >> All this use of raw API and HWNDs is unneccessay.
> >> *****
>
> >> > =A0 =A0// destroy old window and attach new one
> >> > =A0 =A0DestroyWindow(pWnd->Detach());
> >> > =A0 =A0pWnd->Attach(hNew);
> >> > =A0 =A0m_hwnd =3D hNew;
>
> >> ****
> >> Get rid of all the above lines.
>
> >> The convoluted nature of what you are doing is probably what leads to =
the assertion
> >> failure. =A0I wouldn't even try to debug this code, I would rewrite it=
 as indicated. =A0Then,
> >> and only then, if there is still a bug, would I worry about it.
>
> ****
> Since MFC does not normally support multiple inheritance, there can be so=
me confusing side
> effects here that may account for it. =A0What is the type of the object d=
isplayed by the
> debugger?

it displayes the expected type (CQComboBox)

>
> Is there a reason you chose to use multiple inheritance over direct inher=
itance? =A0You are
> working in unsupported areas here.

of course;-) i have a baseclass (CQControl) from with CQButton,
CQTree, CQComboBox and so on derive. Each derived class uses multiple
inheritance to derive from CQControl and its MFC-class. By doind this,
i can do the following:

void SomeFunction(CQControl* pCtrl)
{
	pCtrl->QResetContent();
	// add an red blinking element with id ELEMENT_ID to the control
	pCtrl->QElmSet(ELEMENT_ID, QDS_SHOWN|QDS_BLINK, DYE_RED);
	// set text of element ELEMENT_ID with detail id DETAIL_ID to "Some
Text"
	// and add an image
	pCtrl->QDtlSet(ELEMENT_ID, DETAIL_ID, _T("Some Text"),
ELEMENT_IMAGE);
	// Select element ELEMENT_ID
	pCtrl->QSelectionSet(ELEMENT_ID);
}

if pCtrl is a CQListView, you set element-row ELEMENT_ID, detail-
column DETAIL_ID to image ELEMENT_IMAGE, detail DETAIL_ID. if pCtrl is
a CQButton and you have more than one element, you get a multibutton.
if you dont have "columns" (Button, ListBox,..), the details appear
tab-separated. So you have the same syntax for all controls. Use in
programm: guess you have a function that shall fill a selection-
control with user-names and some additional infos (an icon per user or
a user-state-color and so on). this function just gets a CQControl*
and fills it. if it fills a Listview, a Treeview, a ListBox, a
ComboBox or even a Button just depents on the design of the GUI. More:
CQControl uses a special worker thread and does all the syncronisation
needed, so you could call the above SomeFunction() from ANY Thread;-)


0
clqrq (258)
11/11/2008 1:51:17 PM
See below...
On Tue, 11 Nov 2008 05:51:17 -0800 (PST), ".rhavin grobert" <clqrq@yahoo.de> wrote:

>On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> See below...
>> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> >> See below...
>>
>> >> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >> >a CComboBox and CQControl derived control shall recreate itself, if
>> >> >the styles given in resource not match the style required for toe
>> >> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
>> >> >to correctly modify this style with ModifyStyle(), the recreation is
>> >> >called and works.
>>
>> >> ****
>> >> The error is that you did not do this at design time. �Essentially, I treat the failure to
>> >> have the wrong styles as an error. �Not sure why you are bothering to work around a bug
>> >> that shouldn't exist. �If this happens, you ASSERT and then fix the dialog at design time,
>> >> and omit ALL the code below.
>> >> CComboBox is not *supposed* to be able to modify this style after the control is created,
>> >> so it is not "unable to correctly modify this style" because it was never defined that
>> >> this is even possible.
>> >> ****
>>
>> >thats why i recreate it.
>>
>> ***
>> My point is, a program which has one of these which is NOT defined as CBS_OWNERDRAWFIXED
>> is an erroneous program, so you fix it in the dialog template once, and never again worry
>> about it.
>> ****
>
>if there's no way to let my code correct the error, i'd assert. but i
>thought to use this flags myself, e.g. recreate a control with the
>appropriate windowsflags needed for the control, and use the user-
>defined flags for my own implementation (in this case, calling a user-
>defined drawing routine instead of my own default drawing routine.)
****
You should not go to extensive effort to correct a defect that can be corrected at design
time.  
****
>
>>
>> >> >____________________________________________
>> >> >//-----------------------------------------------------------------------
>> >> >// recreate the underlying hwnd to match required styles
>> >> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
>> >> >{
>> >> > � �CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
>>
>> >> ****
>> >> This is unnecessary; 'this' is already the CWnd *. �So there is no need for the above
>> >> line.
>>
>> >no it is not. 'this' is a CQControl that has no CWnd as baseclass! for
>> >example, the
>> >CQComboBox is a public CComboBox, public CQControl.
>>
>> ****
>> That's a different question than the one you asked. �You did not specify that you are
>> using multiple inheritance.
>
>i did'nt say i'm not using it;-)  But you're right, assuming direct(?)
>inheritance is the default.
****
On the whole, MFC is not multiple-inheritance friendly.  You can get into all kinds of
problems using multiple-inheritance in MFC, which is why most of us avoid it.

ATL and COM use it, but they use it *very carefully*.  And they don't use it for ordinary
controls, but special ATL and COM objects
****
>>
>> But in that case, FromHandle is sufficient.
>> ****
>
>i just wanted to be shure.
>
>>
>> >> ****> � �ASSERT(pWnd != NULL);
>> >> > � �ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
>> >> > � �if (pWnd == NULL)
>> >> > � � � � � �return false;
>>
>> >> ****
>> >> The above statements are meaningless. �You already have 'this' or you wouldn't be here. It
>> >> doesn't matter about what map it is in; you shouldn't care, either.
>>
>> >see above.
>>
>> ****
>> You have to provide *all* relevant information in order to get a correct answer
>> ****
>>
>> >> Note that I use this technique rather often to create a control in a space formerly
>> >> occupied by a CStatic, so I'm changing the entire control type. �This code is FAR too
>> >> complicated for such a simple task.
>> >> ****
>>
>> >a static in Dialog-Editor would not look like a combobox.
>>
>> >> > � �CRect rc;
>> >> > � �HWND hParent = GetParent(m_hwnd); � � � � � � � // [1]
>>
>> >> ****
>> >> CWnd * parent = GetParent();
>> >> ****
>>
>> >wrong. see above.
>>
>> ****
>> If you use multiple inheritance, a previously unstated case, then yes. �But you can't ask
>> a question without giving all relevant information and expect to get a relevant answer
>> ****
>> >> > � �// get position and size of current window
>> >> > � �GetWindowRect(m_hwnd, &rc); � � � � � � � � � � � � � � � � � � � // [2]
>>
>> >> ****
>> >> I'm surprised this even compiles. �There is no need to use the raw HWND. �You could just
>> >> have written
>> >> � � � � GetWindowRect(&rc);
>> >> and get everything you need.
>>
>> >see above;-)
>>
>> >> > � �// following fn's need width and size, we recycle rc
>> >> > � �rc.right �= rc.Width(); � � � � � � � � � � � � � � � � � � � � � � � � � � � � �// [3]
>> >> > � �rc.bottom = rc.Height(); � � � � � � � � � � � � � � � � � � � � � � � � � �// [4]
>>
>> >> ***
>> >> This code is incorrect. �You must not set the right and bottom in this fashion, because
>> >> you are working with the window rect, and the width and height are independent of the
>> >> coordinate system. �Lose the two assignments above.
>>
>> >> > � �// translate into parents coordinates
>> >> > � �ScreenToClient(hParent, &rc.TopLeft()); � � � � � � � � � � � �// [5]
>>
>> >> ****
>> >> Why are you not doing something as simple as
>> >> � � � � � � � � CRect rc;
>> >> � � � � � � � � GetWindowRect(&rc);
>> >> � � � � � � � � GetParent()->ScreenToClient(&rc);
>> >> this is all you need. �You have a complex and convoluted solution to a simple problem.
>> >> Just translating the top/left coordinate makes no sense, because it will produce a window
>> >> that has the wrong size.
>>
>> >no. everything works pretty well. i you insist, one could of course
>> >define a struct RECT_ that has let, top, width and height members, but
>> >apart from that, my way is completely ok.
>>
>> ****
>> Why do you need to define a new structure? �You can just do
>> � � � � CRect rc;
>> � � � � ::GetWindowRect(m_hWnd, &rc);
>> � � � � ::ScreenToClient(parent, &rc);
>> where, now that I know you are using multiple inheritance, is still simpler than the
>> complex code you wrote. �And by setting the right and bottom to the Width() and Height(),
>> BEFORE transforming the top and left, you still get the wrong size.
>> ****
>
>�hm, no..  both rects are in pixel.
****
Consider the following: the rect is in the more-or-less middle of the screen, and
somewhere inside of the window.

Let the screen coordinates be 600,400, 700, 500, that is, it is a 100x100 control
physically at 600,400.

You set rc.right=rc.Width() and rc.bottom=rc.Height().  So we have
	rc.right = 100;
	rc.bottom = 100;

Let the (0,0) of the client area of the window that contains the control be at 400, 200 in
screen coordinates.

Now we transform with ScreenToClient the initial coordinates, just top and left, to client
coordinates.  In client coordinates, 600,400 translates to 200, 200 in client coordinates.
So you have a rectangle that starts at 200,200 and ends at 100,100, when your goal is to
have one that starts at 200,200 and goes to 300,300.  Since right < left and bottom < top,
what you have is actually an illegal rectangle.

Had you just done ScreenToClient on the whole rectangle, you would have gotten
	200,200, 300, 300
which is what you would want.  right and bottom are not distances, but absolute positions
within the coordinate system in question, which in this case is the client coordinate
system (after translation).  But you translate left and top as coordinates and right and
bottom as distances.  This is erroneous.
****
>
>>
>> >> You have five overly complicated lines doing what two trivial lines will accomplish.
>> >> ****
>>
>> >> > � �// let derived class modify rc
>> >> > � �OnCreationRect(rc);
>>
>> >> ****
>> >> I have no idea what this does because there is no handler called OnCreationRect and you
>> >> have not given the code for this, but there's nothing I know that needs to be done to this
>> >> rectangle once you have it.
>> >> ****
>>
>> >in this case, the derived class uses this virtual as following:
>>
>> >void CQComboBox::OnCreationRect(RECT& rc)
>> >{
>> > � �RECT rcDropped;
>> > � �GetDroppedControlRect(&rcDropped);
>> > � �rc.bottom = rcDropped.bottom - rcDropped.top;
>> >}
>>
>> ****
>> Using the 'On' prefix, which is used for handlers, is confusing. �Calling it something
>> meaningful like ComputeDroppedRect might have made it less ambiguous as to what was going
>> on.
>> ****
>>
>> >> > � �// create a new window at current windows coordinates
>> >> > � �HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", dwStyle,
>> >> > � � � � � �rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
>> >> > � � � � � �::AfxGetInstanceHandle(), NULL);
>>
>> >> ****
>> >> Why are you using the raw CreateWindowEx call? �You can do this trivially in MFC:
>>
>> >> � � � � CWnd temp;
>> >> � � � � � � � � temp.CreateEx(dwStyleEx, QGetClassName(), _T(""), dwStyle, rc,
>> >> � � � � � � � � � � � � GetDlgCtrlId(), parent);
>> >> Note how simple this is. �For that matter, does CQControl have a Create method that would
>> >> be better?
>>
>> >> I have no idea why you have chosen to change the control ID by setting it to 0; this kills
>> >> off all your handlers in the parent window. �For a brief moment you will have two controls
>> >> with the same ID, but this will be changed momentarily, and causes no harm.
>>
>> >oh, i thought it was hMenu.
>>
>> ****
>> Note that it is specified as being the hMenu for a top-level window and the control ID for
>> a child window. �From the documentation:
>>
>> "For a child window, hMenu specifies the child-window identifer, an integer value..."
>>
>> It will have to be cast to an HMENU to satisfy the compiler.
>> � � � � � � � � � � � � � � � � joe
>> ****
>>
>>
>>
>> >> But what you didn't do was make sure it is in the right place in the Z-order
>> >> � � � � temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
>> >> � � � � DestroyWindow();
>> >> � � � � Attach(temp.Detach());
>>
>> >> All this use of raw API and HWNDs is unneccessay.
>> >> *****
>>
>> >> > � �// destroy old window and attach new one
>> >> > � �DestroyWindow(pWnd->Detach());
>> >> > � �pWnd->Attach(hNew);
>> >> > � �m_hwnd = hNew;
>>
>> >> ****
>> >> Get rid of all the above lines.
>>
>> >> The convoluted nature of what you are doing is probably what leads to the assertion
>> >> failure. �I wouldn't even try to debug this code, I would rewrite it as indicated. �Then,
>> >> and only then, if there is still a bug, would I worry about it.
>>
>> ****
>> Since MFC does not normally support multiple inheritance, there can be some confusing side
>> effects here that may account for it. �What is the type of the object displayed by the
>> debugger?
>
>it displayes the expected type (CQComboBox)
****
Then you should not be seeing the error.  But, as I indicated, MFC does not play well with
multiple inheritance, and virtual destructors in a multiple inheritance situation can have
interesting consequences.  You're off into uncharted territory here.
****
>
>>
>> Is there a reason you chose to use multiple inheritance over direct inheritance? �You are
>> working in unsupported areas here.
>
>of course;-) i have a baseclass (CQControl) from with CQButton,
>CQTree, CQComboBox and so on derive. Each derived class uses multiple
>inheritance to derive from CQControl and its MFC-class. By doind this,
>i can do the following:
>
>void SomeFunction(CQControl* pCtrl)
>{
>	pCtrl->QResetContent();
>	// add an red blinking element with id ELEMENT_ID to the control
>	pCtrl->QElmSet(ELEMENT_ID, QDS_SHOWN|QDS_BLINK, DYE_RED);
>	// set text of element ELEMENT_ID with detail id DETAIL_ID to "Some
>Text"
>	// and add an image
>	pCtrl->QDtlSet(ELEMENT_ID, DETAIL_ID, _T("Some Text"),
>ELEMENT_IMAGE);
>	// Select element ELEMENT_ID
>	pCtrl->QSelectionSet(ELEMENT_ID);
>}
>
>if pCtrl is a CQListView, you set element-row ELEMENT_ID, detail-
>column DETAIL_ID to image ELEMENT_IMAGE, detail DETAIL_ID. if pCtrl is
>a CQButton and you have more than one element, you get a multibutton.
>if you dont have "columns" (Button, ListBox,..), the details appear
>tab-separated. So you have the same syntax for all controls. Use in
>programm: guess you have a function that shall fill a selection-
>control with user-names and some additional infos (an icon per user or
>a user-state-color and so on). this function just gets a CQControl*
>and fills it. if it fills a Listview, a Treeview, a ListBox, a
>ComboBox or even a Button just depents on the design of the GUI. More:
>CQControl uses a special worker thread and does all the syncronisation
>needed, so you could call the above SomeFunction() from ANY Thread;-)
****
Yes, it is a cool idea, but as I've indicated, you are out into seriously uncharted
territory here, and most of the ideas are not supported by the MFC framework, which
aggressively is single-inheritance.

You can have the same syntax for all controls without requiring multiple inheritance, but
I agree it is painful to duplicate code.  As far as I know, no one has succeeded in doing
this.  I tried it myself some years ago for the same purposes, and after a lot of
newsgroup discussions, the verdict at that time was "You are never going to win at this,
don't bother", and I gave it up.  Nothing has changed in the intervening decade since I
tried this, so it probably doesn't work today, either.

It's not that you have a bad idea, but that you have an idea that is probably incompatible
with how MFC is designed to work.
				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 (15972)
11/11/2008 4:42:50 PM
On 11 Nov., 17:42, Joseph M. Newcomer <newco...@flounder.com> wrote:
> See below...
>
> On Tue, 11 Nov 2008 05:51:17 -0800 (PST), ".rhavin grobert" <cl...@yahoo.=
de> wrote:
> >On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
> >> See below...
> >> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" <cl...@yah=
oo.de> wrote:
> >> >On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
> >> >> See below...
>
> >> >> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@=
yahoo.de> wrote:
> >> >> >a CComboBox and CQControl derived control shall recreate itself, i=
f
> >> >> >the styles given in resource not match the style required for toe
> >> >> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is un=
able
> >> >> >to correctly modify this style with ModifyStyle(), the recreation =
is
> >> >> >called and works.
>
> >> >> ****
> >> >> The error is that you did not do this at design time. =A0Essentiall=
y, I treat the failure to
> >> >> have the wrong styles as an error. =A0Not sure why you are botherin=
g to work around a bug
> >> >> that shouldn't exist. =A0If this happens, you ASSERT and then fix t=
he dialog at design time,
> >> >> and omit ALL the code below.
> >> >> CComboBox is not *supposed* to be able to modify this style after t=
he control is created,
> >> >> so it is not "unable to correctly modify this style" because it was=
 never defined that
> >> >> this is even possible.
> >> >> ****
>
> >> >thats why i recreate it.
>
> >> ***
> >> My point is, a program which has one of these which is NOT defined as =
CBS_OWNERDRAWFIXED
> >> is an erroneous program, so you fix it in the dialog template once, an=
d never again worry
> >> about it.
> >> ****
>
> >if there's no way to let my code correct the error, i'd assert. but i
> >thought to use this flags myself, e.g. recreate a control with the
> >appropriate windowsflags needed for the control, and use the user-
> >defined flags for my own implementation (in this case, calling a user-
> >defined drawing routine instead of my own default drawing routine.)
>
> ****
> You should not go to extensive effort to correct a defect that can be cor=
rected at design
> time. =A0
> ****
>
> >> >> >____________________________________________
> >> >> >//----------------------------------------------------------------=
-------
> >> >> >// recreate the underlying hwnd to match required styles
> >> >> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
> >> >> >{
> >> >> > =A0 =A0CWnd* pWnd =3D CWnd::FromHandlePermanent(m_hwnd);
>
> >> >> ****
> >> >> This is unnecessary; 'this' is already the CWnd *. =A0So there is n=
o need for the above
> >> >> line.
>
> >> >no it is not. 'this' is a CQControl that has no CWnd as baseclass! fo=
r
> >> >example, the
> >> >CQComboBox is a public CComboBox, public CQControl.
>
> >> ****
> >> That's a different question than the one you asked. =A0You did not spe=
cify that you are
> >> using multiple inheritance.
>
> >i did'nt say i'm not using it;-) =A0But you're right, assuming direct(?)
> >inheritance is the default.
>
> ****
> On the whole, MFC is not multiple-inheritance friendly. =A0You can get in=
to all kinds of
> problems using multiple-inheritance in MFC, which is why most of us avoid=
 it.
>
> ATL and COM use it, but they use it *very carefully*. =A0And they don't u=
se it for ordinary
> controls, but special ATL and COM objects
> ****
>
> >> But in that case, FromHandle is sufficient.
> >> ****
>
> >i just wanted to be shure.
>
> >> >> ****> =A0 =A0ASSERT(pWnd !=3D NULL);
> >> >> > =A0 =A0ASSERT(pWnd =3D=3D CWnd::FromHandle(m_hwnd));
> >> >> > =A0 =A0if (pWnd =3D=3D NULL)
> >> >> > =A0 =A0 =A0 =A0 =A0 =A0return false;
>
> >> >> ****
> >> >> The above statements are meaningless. =A0You already have 'this' or=
 you wouldn't be here. It
> >> >> doesn't matter about what map it is in; you shouldn't care, either.
>
> >> >see above.
>
> >> ****
> >> You have to provide *all* relevant information in order to get a corre=
ct answer
> >> ****
>
> >> >> Note that I use this technique rather often to create a control in =
a space formerly
> >> >> occupied by a CStatic, so I'm changing the entire control type. =A0=
This code is FAR too
> >> >> complicated for such a simple task.
> >> >> ****
>
> >> >a static in Dialog-Editor would not look like a combobox.
>
> >> >> > =A0 =A0CRect rc;
> >> >> > =A0 =A0HWND hParent =3D GetParent(m_hwnd); =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 // [1]
>
> >> >> ****
> >> >> CWnd * parent =3D GetParent();
> >> >> ****
>
> >> >wrong. see above.
>
> >> ****
> >> If you use multiple inheritance, a previously unstated case, then yes.=
 =A0But you can't ask
> >> a question without giving all relevant information and expect to get a=
 relevant answer
> >> ****
> >> >> > =A0 =A0// get position and size of current window
> >> >> > =A0 =A0GetWindowRect(m_hwnd, &rc); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // [2]
>
> >> >> ****
> >> >> I'm surprised this even compiles. =A0There is no need to use the ra=
w HWND. =A0You could just
> >> >> have written
> >> >> =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> >> >> and get everything you need.
>
> >> >see above;-)
>
> >> >> > =A0 =A0// following fn's need width and size, we recycle rc
> >> >> > =A0 =A0rc.right =A0=3D rc.Width(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0// [3]
> >> >> > =A0 =A0rc.bottom =3D rc.Height(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// =
[4]
>
> >> >> ***
> >> >> This code is incorrect. =A0You must not set the right and bottom in=
 this fashion, because
> >> >> you are working with the window rect, and the width and height are =
independent of the
> >> >> coordinate system. =A0Lose the two assignments above.
>
> >> >> > =A0 =A0// translate into parents coordinates
> >> >> > =A0 =A0ScreenToClient(hParent, &rc.TopLeft()); =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// [5]
>
> >> >> ****
> >> >> Why are you not doing something as simple as
> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CRect rc;
> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetWindowRect(&rc);
> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetParent()->ScreenToClient(&rc);
> >> >> this is all you need. =A0You have a complex and convoluted solution=
 to a simple problem.
> >> >> Just translating the top/left coordinate makes no sense, because it=
 will produce a window
> >> >> that has the wrong size.
>
> >> >no. everything works pretty well. i you insist, one could of course
> >> >define a struct RECT_ that has let, top, width and height members, bu=
t
> >> >apart from that, my way is completely ok.
>
> >> ****
> >> Why do you need to define a new structure? =A0You can just do
> >> =A0 =A0 =A0 =A0 CRect rc;
> >> =A0 =A0 =A0 =A0 ::GetWindowRect(m_hWnd, &rc);
> >> =A0 =A0 =A0 =A0 ::ScreenToClient(parent, &rc);
> >> where, now that I know you are using multiple inheritance, is still si=
mpler than the
> >> complex code you wrote. =A0And by setting the right and bottom to the =
Width() and Height(),
> >> BEFORE transforming the top and left, you still get the wrong size.
> >> ****
>
> >=E4hm, no.. =A0both rects are in pixel.
>
> ****
> Consider the following: the rect is in the more-or-less middle of the scr=
een, and
> somewhere inside of the window.
>
> Let the screen coordinates be 600,400, 700, 500, that is, it is a 100x100=
 control
> physically at 600,400.
>
> You set rc.right=3Drc.Width() and rc.bottom=3Drc.Height(). =A0So we have
> =A0 =A0 =A0 =A0 rc.right =3D 100;
> =A0 =A0 =A0 =A0 rc.bottom =3D 100;
>
> Let the (0,0) of the client area of the window that contains the control =
be at 400, 200 in
> screen coordinates.
>
> Now we transform with ScreenToClient the initial coordinates, just top an=
d left, to client
> coordinates. =A0In client coordinates, 600,400 translates to 200, 200 in =
client coordinates.
> So you have a rectangle that starts at 200,200 and ends at 100,100, when =
your goal is to
> have one that starts at 200,200 and goes to 300,300. =A0Since right < lef=
t and bottom < top,
> what you have is actually an illegal rectangle.

in the view of "rectangle", you're right. but i have now something
different: i have struct that has x,y,width,height as needed by
CreateWindowEx(). but to dont make thinks to complicated for other i
now use the following struct:

//-------------------------------------------------------------------------=
----
struct SQDim {
	UINT nLeft;
	UINT nTop;
	UINT nWidth;
	UINT nHeight;

	inline SQDim(UINT left =3D 0, UINT top =3D 0, UINT width =3D 0, UINT heigh=
t
=3D 0) :
		nLeft(left), nTop(top), nWidth(width), nHeight(height) {};

	inline SQDim const& operator =3D(SQDim const& rDim)
		{memcpy(this, &rDim, sizeof(this));};

	inline SQDim const& operator =3D(RECT const& rRect)
	{
		nLeft   =3D rRect.left;
		nTop    =3D rRect.top;
		nWidth  =3D rRect.right  - nLeft;
		nHeight =3D rRect.bottom - nTop;
	};

	inline operator RECT() const
		{RECT rc =3D {nLeft, nTop, nWidth + nLeft, nHeight + nTop}; return
rc;};
};

>
> Had you just done ScreenToClient on the whole rectangle, you would have g=
otten
> =A0 =A0 =A0 =A0 200,200, 300, 300
> which is what you would want. =A0right and bottom are not distances, but =
absolute positions
> within the coordinate system in question, which in this case is the clien=
t coordinate
> system (after translation). =A0But you translate left and top as coordina=
tes and right and
> bottom as distances. =A0This is erroneous.
> ****
>
> >> >> You have five overly complicated lines doing what two trivial lines=
 will accomplish.
> >> >> ****
>
> >> >> > =A0 =A0// let derived class modify rc
> >> >> > =A0 =A0OnCreationRect(rc);
>
> >> >> ****
> >> >> I have no idea what this does because there is no handler called On=
CreationRect and you
> >> >> have not given the code for this, but there's nothing I know that n=
eeds to be done to this
> >> >> rectangle once you have it.
> >> >> ****
>
> >> >in this case, the derived class uses this virtual as following:
>
> >> >void CQComboBox::OnCreationRect(RECT& rc)
> >> >{
> >> > =A0 =A0RECT rcDropped;
> >> > =A0 =A0GetDroppedControlRect(&rcDropped);
> >> > =A0 =A0rc.bottom =3D rcDropped.bottom - rcDropped.top;
> >> >}
>
> >> ****
> >> Using the 'On' prefix, which is used for handlers, is confusing. =A0Ca=
lling it something
> >> meaningful like ComputeDroppedRect might have made it less ambiguous a=
s to what was going
> >> on.
> >> ****
>
> >> >> > =A0 =A0// create a new window at current windows coordinates
> >> >> > =A0 =A0HWND hNew =3D CreateWindowEx(dwStyleEx, QGetClassName(), "=
", dwStyle,
> >> >> > =A0 =A0 =A0 =A0 =A0 =A0rc.left, rc.top, rc.right, rc.bottom, hPar=
ent, 0,
> >> >> > =A0 =A0 =A0 =A0 =A0 =A0::AfxGetInstanceHandle(), NULL);
>
> >> >> ****
> >> >> Why are you using the raw CreateWindowEx call? =A0You can do this t=
rivially in MFC:
>
> >> >> =A0 =A0 =A0 =A0 CWnd temp;
> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 temp.CreateEx(dwStyleEx, QGetClassN=
ame(), _T(""), dwStyle, rc,
> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GetDlgCtrlId(), par=
ent);
> >> >> Note how simple this is. =A0For that matter, does CQControl have a =
Create method that would
> >> >> be better?
>
> >> >> I have no idea why you have chosen to change the control ID by sett=
ing it to 0; this kills
> >> >> off all your handlers in the parent window. =A0For a brief moment y=
ou will have two controls
> >> >> with the same ID, but this will be changed momentarily, and causes =
no harm.
>
> >> >oh, i thought it was hMenu.
>
> >> ****
> >> Note that it is specified as being the hMenu for a top-level window an=
d the control ID for
> >> a child window. =A0From the documentation:
>
> >> "For a child window, hMenu specifies the child-window identifer, an in=
teger value..."
>
> >> It will have to be cast to an HMENU to satisfy the compiler.
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joe
> >> ****
>
> >> >> But what you didn't do was make sure it is in the right place in th=
e Z-order
> >> >> =A0 =A0 =A0 =A0 temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SW=
P_NOSIZE);
> >> >> =A0 =A0 =A0 =A0 DestroyWindow();
> >> >> =A0 =A0 =A0 =A0 Attach(temp.Detach());
>
> >> >> All this use of raw API and HWNDs is unneccessay.
> >> >> *****
>
> >> >> > =A0 =A0// destroy old window and attach new one
> >> >> > =A0 =A0DestroyWindow(pWnd->Detach());
> >> >> > =A0 =A0pWnd->Attach(hNew);
> >> >> > =A0 =A0m_hwnd =3D hNew;
>
> >> >> ****
> >> >> Get rid of all the above lines.
>
> >> >> The convoluted nature of what you are doing is probably what leads =
to the assertion
> >> >> failure. =A0I wouldn't even try to debug this code, I would rewrite=
 it as indicated. =A0Then,
> >> >> and only then, if there is still a bug, would I worry about it.
>
> >> ****
> >> Since MFC does not normally support multiple inheritance, there can be=
 some confusing side
> >> effects here that may account for it. =A0What is the type of the objec=
t displayed by the
> >> debugger?
>
> >it displayes the expected type (CQComboBox)
>
> ****
> Then you should not be seeing the error. =A0But, as I indicated, MFC does=
 not play well with
> multiple inheritance, and virtual destructors in a multiple inheritance s=
ituation can have
> interesting consequences. =A0You're off into uncharted territory here.
> ****
>
> >> Is there a reason you chose to use multiple inheritance over direct in=
heritance? =A0You are
> >> working in unsupported areas here.
>
> >of course;-) i have a baseclass (CQControl) from with CQButton,
> >CQTree, CQComboBox and so on derive. Each derived class uses multiple
> >inheritance to derive from CQControl and its MFC-class. By doind this,
> >i can do the following:
>
> >void SomeFunction(CQControl* pCtrl)
> >{
> > =A0 =A0pCtrl->QResetContent();
> > =A0 =A0// add an red blinking element with id ELEMENT_ID to the control
> > =A0 =A0pCtrl->QElmSet(ELEMENT_ID, QDS_SHOWN|QDS_BLINK, DYE_RED);
> > =A0 =A0// set text of element ELEMENT_ID with detail id DETAIL_ID to "S=
ome
> >Text"
> > =A0 =A0// and add an image
> > =A0 =A0pCtrl->QDtlSet(ELEMENT_ID, DETAIL_ID, _T("Some Text"),
> >ELEMENT_IMAGE);
> > =A0 =A0// Select element ELEMENT_ID
> > =A0 =A0pCtrl->QSelectionSet(ELEMENT_ID);
> >}
>
> >if pCtrl is a CQListView, you set element-row ELEMENT_ID, detail-
> >column DETAIL_ID to image ELEMENT_IMAGE, detail DETAIL_ID. if pCtrl is
> >a CQButton and you have more than one element, you get a multibutton.
> >if you dont have "columns" (Button, ListBox,..), the details appear
> >tab-separated. So you have the same syntax for all controls. Use in
> >programm: guess you have a function that shall fill a selection-
> >control with user-names and some additional infos (an icon per user or
> >a user-state-color and so on). this function just gets a CQControl*
> >and fills it. if it fills a Listview, a Treeview, a ListBox, a
> >ComboBox or even a Button just depents on the design of the GUI. More:
> >CQControl uses a special worker thread and does all the syncronisation
> >needed, so you could call the above SomeFunction() from ANY Thread;-)
>
> ****
> Yes, it is a cool idea, but as I've indicated, you are out into seriously=
 uncharted
> territory here, and most of the ideas are not supported by the MFC framew=
ork, which
> aggressively is single-inheritance.
>
> You can have the same syntax for all controls without requiring multiple =
inheritance, but
> I agree it is painful to duplicate code. =A0As far as I know, no one has =
succeeded in doing
> this.


;-))))))))))))) What i wrote is no "i plan to do this". IT
WORKS! ;-)))


 =A0I tried it myself some years ago for the same purposes, and after a
lot of
> newsgroup discussions, the verdict at that time was "You are never going =
to win at this,
> don't bother", and I gave it up. =A0Nothing has changed in the intervenin=
g decade since I
> tried this, so it probably doesn't work today, either.
>
> It's not that you have a bad idea, but that you have an idea that is prob=
ably incompatible
> with how MFC is designed to work.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joe
> ****
>
> Joseph M. Newcomer [MVP]
> email: newco...@flounder.com
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm

0
clqrq (258)
11/11/2008 5:16:35 PM
See below...
On Tue, 11 Nov 2008 09:16:35 -0800 (PST), ".rhavin grobert" <clqrq@yahoo.de> wrote:

>On 11 Nov., 17:42, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> See below...
>>
>> On Tue, 11 Nov 2008 05:51:17 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> >> See below...
>> >> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >> >On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> >> >> See below...
>>
>> >> >> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" <cl...@yahoo.de> wrote:
>> >> >> >a CComboBox and CQControl derived control shall recreate itself, if
>> >> >> >the styles given in resource not match the style required for toe
>> >> >> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable
>> >> >> >to correctly modify this style with ModifyStyle(), the recreation is
>> >> >> >called and works.
>>
>> >> >> ****
>> >> >> The error is that you did not do this at design time. �Essentially, I treat the failure to
>> >> >> have the wrong styles as an error. �Not sure why you are bothering to work around a bug
>> >> >> that shouldn't exist. �If this happens, you ASSERT and then fix the dialog at design time,
>> >> >> and omit ALL the code below.
>> >> >> CComboBox is not *supposed* to be able to modify this style after the control is created,
>> >> >> so it is not "unable to correctly modify this style" because it was never defined that
>> >> >> this is even possible.
>> >> >> ****
>>
>> >> >thats why i recreate it.
>>
>> >> ***
>> >> My point is, a program which has one of these which is NOT defined as CBS_OWNERDRAWFIXED
>> >> is an erroneous program, so you fix it in the dialog template once, and never again worry
>> >> about it.
>> >> ****
>>
>> >if there's no way to let my code correct the error, i'd assert. but i
>> >thought to use this flags myself, e.g. recreate a control with the
>> >appropriate windowsflags needed for the control, and use the user-
>> >defined flags for my own implementation (in this case, calling a user-
>> >defined drawing routine instead of my own default drawing routine.)
>>
>> ****
>> You should not go to extensive effort to correct a defect that can be corrected at design
>> time. �
>> ****
>>
>> >> >> >____________________________________________
>> >> >> >//-----------------------------------------------------------------------
>> >> >> >// recreate the underlying hwnd to match required styles
>> >> >> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
>> >> >> >{
>> >> >> > � �CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
>>
>> >> >> ****
>> >> >> This is unnecessary; 'this' is already the CWnd *. �So there is no need for the above
>> >> >> line.
>>
>> >> >no it is not. 'this' is a CQControl that has no CWnd as baseclass! for
>> >> >example, the
>> >> >CQComboBox is a public CComboBox, public CQControl.
>>
>> >> ****
>> >> That's a different question than the one you asked. �You did not specify that you are
>> >> using multiple inheritance.
>>
>> >i did'nt say i'm not using it;-) �But you're right, assuming direct(?)
>> >inheritance is the default.
>>
>> ****
>> On the whole, MFC is not multiple-inheritance friendly. �You can get into all kinds of
>> problems using multiple-inheritance in MFC, which is why most of us avoid it.
>>
>> ATL and COM use it, but they use it *very carefully*. �And they don't use it for ordinary
>> controls, but special ATL and COM objects
>> ****
>>
>> >> But in that case, FromHandle is sufficient.
>> >> ****
>>
>> >i just wanted to be shure.
>>
>> >> >> ****> � �ASSERT(pWnd != NULL);
>> >> >> > � �ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
>> >> >> > � �if (pWnd == NULL)
>> >> >> > � � � � � �return false;
>>
>> >> >> ****
>> >> >> The above statements are meaningless. �You already have 'this' or you wouldn't be here. It
>> >> >> doesn't matter about what map it is in; you shouldn't care, either.
>>
>> >> >see above.
>>
>> >> ****
>> >> You have to provide *all* relevant information in order to get a correct answer
>> >> ****
>>
>> >> >> Note that I use this technique rather often to create a control in a space formerly
>> >> >> occupied by a CStatic, so I'm changing the entire control type. �This code is FAR too
>> >> >> complicated for such a simple task.
>> >> >> ****
>>
>> >> >a static in Dialog-Editor would not look like a combobox.
>>
>> >> >> > � �CRect rc;
>> >> >> > � �HWND hParent = GetParent(m_hwnd); � � � � � � � // [1]
>>
>> >> >> ****
>> >> >> CWnd * parent = GetParent();
>> >> >> ****
>>
>> >> >wrong. see above.
>>
>> >> ****
>> >> If you use multiple inheritance, a previously unstated case, then yes. �But you can't ask
>> >> a question without giving all relevant information and expect to get a relevant answer
>> >> ****
>> >> >> > � �// get position and size of current window
>> >> >> > � �GetWindowRect(m_hwnd, &rc); � � � � � � � � � � � � � � � � � � � // [2]
>>
>> >> >> ****
>> >> >> I'm surprised this even compiles. �There is no need to use the raw HWND. �You could just
>> >> >> have written
>> >> >> � � � � GetWindowRect(&rc);
>> >> >> and get everything you need.
>>
>> >> >see above;-)
>>
>> >> >> > � �// following fn's need width and size, we recycle rc
>> >> >> > � �rc.right �= rc.Width(); � � � � � � � � � � � � � � � � � � � � � � � � � � � � �// [3]
>> >> >> > � �rc.bottom = rc.Height(); � � � � � � � � � � � � � � � � � � � � � � � � � �// [4]
>>
>> >> >> ***
>> >> >> This code is incorrect. �You must not set the right and bottom in this fashion, because
>> >> >> you are working with the window rect, and the width and height are independent of the
>> >> >> coordinate system. �Lose the two assignments above.
>>
>> >> >> > � �// translate into parents coordinates
>> >> >> > � �ScreenToClient(hParent, &rc.TopLeft()); � � � � � � � � � � � �// [5]
>>
>> >> >> ****
>> >> >> Why are you not doing something as simple as
>> >> >> � � � � � � � � CRect rc;
>> >> >> � � � � � � � � GetWindowRect(&rc);
>> >> >> � � � � � � � � GetParent()->ScreenToClient(&rc);
>> >> >> this is all you need. �You have a complex and convoluted solution to a simple problem.
>> >> >> Just translating the top/left coordinate makes no sense, because it will produce a window
>> >> >> that has the wrong size.
>>
>> >> >no. everything works pretty well. i you insist, one could of course
>> >> >define a struct RECT_ that has let, top, width and height members, but
>> >> >apart from that, my way is completely ok.
>>
>> >> ****
>> >> Why do you need to define a new structure? �You can just do
>> >> � � � � CRect rc;
>> >> � � � � ::GetWindowRect(m_hWnd, &rc);
>> >> � � � � ::ScreenToClient(parent, &rc);
>> >> where, now that I know you are using multiple inheritance, is still simpler than the
>> >> complex code you wrote. �And by setting the right and bottom to the Width() and Height(),
>> >> BEFORE transforming the top and left, you still get the wrong size.
>> >> ****
>>
>> >�hm, no.. �both rects are in pixel.
>>
>> ****
>> Consider the following: the rect is in the more-or-less middle of the screen, and
>> somewhere inside of the window.
>>
>> Let the screen coordinates be 600,400, 700, 500, that is, it is a 100x100 control
>> physically at 600,400.
>>
>> You set rc.right=rc.Width() and rc.bottom=rc.Height(). �So we have
>> � � � � rc.right = 100;
>> � � � � rc.bottom = 100;
>>
>> Let the (0,0) of the client area of the window that contains the control be at 400, 200 in
>> screen coordinates.
>>
>> Now we transform with ScreenToClient the initial coordinates, just top and left, to client
>> coordinates. �In client coordinates, 600,400 translates to 200, 200 in client coordinates.
>> So you have a rectangle that starts at 200,200 and ends at 100,100, when your goal is to
>> have one that starts at 200,200 and goes to 300,300. �Since right < left and bottom < top,
>> what you have is actually an illegal rectangle.
>
>in the view of "rectangle", you're right. but i have now something
>different: i have struct that has x,y,width,height as needed by
>CreateWindowEx(). but to dont make thinks to complicated for other i
>now use the following struct:
>
>//-----------------------------------------------------------------------------
>struct SQDim {
>	UINT nLeft;
>	UINT nTop;
>	UINT nWidth;
>	UINT nHeight;
>
>	inline SQDim(UINT left = 0, UINT top = 0, UINT width = 0, UINT height
>= 0) :
>		nLeft(left), nTop(top), nWidth(width), nHeight(height) {};
>
>	inline SQDim const& operator =(SQDim const& rDim)
>		{memcpy(this, &rDim, sizeof(this));};
>
>	inline SQDim const& operator =(RECT const& rRect)
>	{
>		nLeft   = rRect.left;
>		nTop    = rRect.top;
>		nWidth  = rRect.right  - nLeft;
>		nHeight = rRect.bottom - nTop;
>	};
>
>	inline operator RECT() const
>		{RECT rc = {nLeft, nTop, nWidth + nLeft, nHeight + nTop}; return
>rc;};
>};
>
>>
>> Had you just done ScreenToClient on the whole rectangle, you would have gotten
>> � � � � 200,200, 300, 300
>> which is what you would want. �right and bottom are not distances, but absolute positions
>> within the coordinate system in question, which in this case is the client coordinate
>> system (after translation). �But you translate left and top as coordinates and right and
>> bottom as distances. �This is erroneous.
>> ****
>>
>> >> >> You have five overly complicated lines doing what two trivial lines will accomplish.
>> >> >> ****
>>
>> >> >> > � �// let derived class modify rc
>> >> >> > � �OnCreationRect(rc);
>>
>> >> >> ****
>> >> >> I have no idea what this does because there is no handler called OnCreationRect and you
>> >> >> have not given the code for this, but there's nothing I know that needs to be done to this
>> >> >> rectangle once you have it.
>> >> >> ****
>>
>> >> >in this case, the derived class uses this virtual as following:
>>
>> >> >void CQComboBox::OnCreationRect(RECT& rc)
>> >> >{
>> >> > � �RECT rcDropped;
>> >> > � �GetDroppedControlRect(&rcDropped);
>> >> > � �rc.bottom = rcDropped.bottom - rcDropped.top;
>> >> >}
>>
>> >> ****
>> >> Using the 'On' prefix, which is used for handlers, is confusing. �Calling it something
>> >> meaningful like ComputeDroppedRect might have made it less ambiguous as to what was going
>> >> on.
>> >> ****
>>
>> >> >> > � �// create a new window at current windows coordinates
>> >> >> > � �HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", dwStyle,
>> >> >> > � � � � � �rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
>> >> >> > � � � � � �::AfxGetInstanceHandle(), NULL);
>>
>> >> >> ****
>> >> >> Why are you using the raw CreateWindowEx call? �You can do this trivially in MFC:
>>
>> >> >> � � � � CWnd temp;
>> >> >> � � � � � � � � temp.CreateEx(dwStyleEx, QGetClassName(), _T(""), dwStyle, rc,
>> >> >> � � � � � � � � � � � � GetDlgCtrlId(), parent);
>> >> >> Note how simple this is. �For that matter, does CQControl have a Create method that would
>> >> >> be better?
>>
>> >> >> I have no idea why you have chosen to change the control ID by setting it to 0; this kills
>> >> >> off all your handlers in the parent window. �For a brief moment you will have two controls
>> >> >> with the same ID, but this will be changed momentarily, and causes no harm.
>>
>> >> >oh, i thought it was hMenu.
>>
>> >> ****
>> >> Note that it is specified as being the hMenu for a top-level window and the control ID for
>> >> a child window. �From the documentation:
>>
>> >> "For a child window, hMenu specifies the child-window identifer, an integer value..."
>>
>> >> It will have to be cast to an HMENU to satisfy the compiler.
>> >> � � � � � � � � � � � � � � � � joe
>> >> ****
>>
>> >> >> But what you didn't do was make sure it is in the right place in the Z-order
>> >> >> � � � � temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
>> >> >> � � � � DestroyWindow();
>> >> >> � � � � Attach(temp.Detach());
>>
>> >> >> All this use of raw API and HWNDs is unneccessay.
>> >> >> *****
>>
>> >> >> > � �// destroy old window and attach new one
>> >> >> > � �DestroyWindow(pWnd->Detach());
>> >> >> > � �pWnd->Attach(hNew);
>> >> >> > � �m_hwnd = hNew;
>>
>> >> >> ****
>> >> >> Get rid of all the above lines.
>>
>> >> >> The convoluted nature of what you are doing is probably what leads to the assertion
>> >> >> failure. �I wouldn't even try to debug this code, I would rewrite it as indicated. �Then,
>> >> >> and only then, if there is still a bug, would I worry about it.
>>
>> >> ****
>> >> Since MFC does not normally support multiple inheritance, there can be some confusing side
>> >> effects here that may account for it. �What is the type of the object displayed by the
>> >> debugger?
>>
>> >it displayes the expected type (CQComboBox)
>>
>> ****
>> Then you should not be seeing the error. �But, as I indicated, MFC does not play well with
>> multiple inheritance, and virtual destructors in a multiple inheritance situation can have
>> interesting consequences. �You're off into uncharted territory here.
>> ****
>>
>> >> Is there a reason you chose to use multiple inheritance over direct inheritance? �You are
>> >> working in unsupported areas here.
>>
>> >of course;-) i have a baseclass (CQControl) from with CQButton,
>> >CQTree, CQComboBox and so on derive. Each derived class uses multiple
>> >inheritance to derive from CQControl and its MFC-class. By doind this,
>> >i can do the following:
>>
>> >void SomeFunction(CQControl* pCtrl)
>> >{
>> > � �pCtrl->QResetContent();
>> > � �// add an red blinking element with id ELEMENT_ID to the control
>> > � �pCtrl->QElmSet(ELEMENT_ID, QDS_SHOWN|QDS_BLINK, DYE_RED);
>> > � �// set text of element ELEMENT_ID with detail id DETAIL_ID to "Some
>> >Text"
>> > � �// and add an image
>> > � �pCtrl->QDtlSet(ELEMENT_ID, DETAIL_ID, _T("Some Text"),
>> >ELEMENT_IMAGE);
>> > � �// Select element ELEMENT_ID
>> > � �pCtrl->QSelectionSet(ELEMENT_ID);
>> >}
>>
>> >if pCtrl is a CQListView, you set element-row ELEMENT_ID, detail-
>> >column DETAIL_ID to image ELEMENT_IMAGE, detail DETAIL_ID. if pCtrl is
>> >a CQButton and you have more than one element, you get a multibutton.
>> >if you dont have "columns" (Button, ListBox,..), the details appear
>> >tab-separated. So you have the same syntax for all controls. Use in
>> >programm: guess you have a function that shall fill a selection-
>> >control with user-names and some additional infos (an icon per user or
>> >a user-state-color and so on). this function just gets a CQControl*
>> >and fills it. if it fills a Listview, a Treeview, a ListBox, a
>> >ComboBox or even a Button just depents on the design of the GUI. More:
>> >CQControl uses a special worker thread and does all the syncronisation
>> >needed, so you could call the above SomeFunction() from ANY Thread;-)
>>
>> ****
>> Yes, it is a cool idea, but as I've indicated, you are out into seriously uncharted
>> territory here, and most of the ideas are not supported by the MFC framework, which
>> aggressively is single-inheritance.
>>
>> You can have the same syntax for all controls without requiring multiple inheritance, but
>> I agree it is painful to duplicate code. �As far as I know, no one has succeeded in doing
>> this.
>
>
>;-))))))))))))) What i wrote is no "i plan to do this". IT
>WORKS! ;-)))
****
It does?  I thought the whole point of this thread was that it doesn't.  It generates an
error in the MFC runtime.  If it worked, you wouldn't have needed to post the question...
				joe
****
>
>
> �I tried it myself some years ago for the same purposes, and after a
>lot of
>> newsgroup discussions, the verdict at that time was "You are never going to win at this,
>> don't bother", and I gave it up. �Nothing has changed in the intervening decade since I
>> tried this, so it probably doesn't work today, either.
>>
>> It's not that you have a bad idea, but that you have an idea that is probably incompatible
>> with how MFC is designed to work.
>> � � � � � � � � � � � � � � � � joe
>> ****
>>
>> Joseph M. Newcomer [MVP]
>> email: newco...@flounder.com
>> Web:http://www.flounder.com
>> MVP Tips:http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15972)
11/12/2008 1:09:27 AM
I've nothing to add to this discussion, but do either of you believe in 
snipping unused parts of the thread?  What a mess!  ;)

-- David

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:e4bkh49irr6eenpsj2covms8l2ms2sq2pf@4ax.com...
> See below...
> On Tue, 11 Nov 2008 09:16:35 -0800 (PST), ".rhavin grobert" 
> <clqrq@yahoo.de> wrote:
>
>>On 11 Nov., 17:42, Joseph M. Newcomer <newco...@flounder.com> wrote:
>>> See below...
>>>
>>> On Tue, 11 Nov 2008 05:51:17 -0800 (PST), ".rhavin grobert" 
>>> <cl...@yahoo.de> wrote:
>>> >On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
>>> >> See below...
>>> >> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" 
>>> >> <cl...@yahoo.de> wrote:
>>> >> >On 10 Nov., 18:59, Joseph M. Newcomer <newco...@flounder.com> wrote:
>>> >> >> See below...
>>>
>>> >> >> On Mon, 10 Nov 2008 08:09:56 -0800 (PST), ".rhavin grobert" 
>>> >> >> <cl...@yahoo.de> wrote:
>>> >> >> >a CComboBox and CQControl derived control shall recreate itself, 
>>> >> >> >if
>>> >> >> >the styles given in resource not match the style required for toe
>>> >> >> >control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is 
>>> >> >> >unable
>>> >> >> >to correctly modify this style with ModifyStyle(), the recreation 
>>> >> >> >is
>>> >> >> >called and works.
>>>
>>> >> >> ****
>>> >> >> The error is that you did not do this at design time. Essentially, 
>>> >> >> I treat the failure to
>>> >> >> have the wrong styles as an error. Not sure why you are bothering 
>>> >> >> to work around a bug
>>> >> >> that shouldn't exist. If this happens, you ASSERT and then fix the 
>>> >> >> dialog at design time,
>>> >> >> and omit ALL the code below.
>>> >> >> CComboBox is not *supposed* to be able to modify this style after 
>>> >> >> the control is created,
>>> >> >> so it is not "unable to correctly modify this style" because it 
>>> >> >> was never defined that
>>> >> >> this is even possible.
>>> >> >> ****
>>>
>>> >> >thats why i recreate it.
>>>
>>> >> ***
>>> >> My point is, a program which has one of these which is NOT defined as 
>>> >> CBS_OWNERDRAWFIXED
>>> >> is an erroneous program, so you fix it in the dialog template once, 
>>> >> and never again worry
>>> >> about it.
>>> >> ****
>>>
>>> >if there's no way to let my code correct the error, i'd assert. but i
>>> >thought to use this flags myself, e.g. recreate a control with the
>>> >appropriate windowsflags needed for the control, and use the user-
>>> >defined flags for my own implementation (in this case, calling a user-
>>> >defined drawing routine instead of my own default drawing routine.)
>>>
>>> ****
>>> You should not go to extensive effort to correct a defect that can be 
>>> corrected at design
>>> time.
>>> ****
>>>
>>> >> >> >____________________________________________
>>> >> >> >//-----------------------------------------------------------------------
>>> >> >> >// recreate the underlying hwnd to match required styles
>>> >> >> >bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx)
>>> >> >> >{
>>> >> >> > CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd);
>>>
>>> >> >> ****
>>> >> >> This is unnecessary; 'this' is already the CWnd *. So there is no 
>>> >> >> need for the above
>>> >> >> line.
>>>
>>> >> >no it is not. 'this' is a CQControl that has no CWnd as baseclass! 
>>> >> >for
>>> >> >example, the
>>> >> >CQComboBox is a public CComboBox, public CQControl.
>>>
>>> >> ****
>>> >> That's a different question than the one you asked. You did not 
>>> >> specify that you are
>>> >> using multiple inheritance.
>>>
>>> >i did'nt say i'm not using it;-) But you're right, assuming direct(?)
>>> >inheritance is the default.
>>>
>>> ****
>>> On the whole, MFC is not multiple-inheritance friendly. You can get into 
>>> all kinds of
>>> problems using multiple-inheritance in MFC, which is why most of us 
>>> avoid it.
>>>
>>> ATL and COM use it, but they use it *very carefully*. And they don't use 
>>> it for ordinary
>>> controls, but special ATL and COM objects
>>> ****
>>>
>>> >> But in that case, FromHandle is sufficient.
>>> >> ****
>>>
>>> >i just wanted to be shure.
>>>
>>> >> >> ****> ASSERT(pWnd != NULL);
>>> >> >> > ASSERT(pWnd == CWnd::FromHandle(m_hwnd));
>>> >> >> > if (pWnd == NULL)
>>> >> >> > return false;
>>>
>>> >> >> ****
>>> >> >> The above statements are meaningless. You already have 'this' or 
>>> >> >> you wouldn't be here. It
>>> >> >> doesn't matter about what map it is in; you shouldn't care, 
>>> >> >> either.
>>>
>>> >> >see above.
>>>
>>> >> ****
>>> >> You have to provide *all* relevant information in order to get a 
>>> >> correct answer
>>> >> ****
>>>
>>> >> >> Note that I use this technique rather often to create a control in 
>>> >> >> a space formerly
>>> >> >> occupied by a CStatic, so I'm changing the entire control type. 
>>> >> >> This code is FAR too
>>> >> >> complicated for such a simple task.
>>> >> >> ****
>>>
>>> >> >a static in Dialog-Editor would not look like a combobox.
>>>
>>> >> >> > CRect rc;
>>> >> >> > HWND hParent = GetParent(m_hwnd); // [1]
>>>
>>> >> >> ****
>>> >> >> CWnd * parent = GetParent();
>>> >> >> ****
>>>
>>> >> >wrong. see above.
>>>
>>> >> ****
>>> >> If you use multiple inheritance, a previously unstated case, then 
>>> >> yes. But you can't ask
>>> >> a question without giving all relevant information and expect to get 
>>> >> a relevant answer
>>> >> ****
>>> >> >> > // get position and size of current window
>>> >> >> > GetWindowRect(m_hwnd, &rc); // [2]
>>>
>>> >> >> ****
>>> >> >> I'm surprised this even compiles. There is no need to use the raw 
>>> >> >> HWND. You could just
>>> >> >> have written
>>> >> >> GetWindowRect(&rc);
>>> >> >> and get everything you need.
>>>
>>> >> >see above;-)
>>>
>>> >> >> > // following fn's need width and size, we recycle rc
>>> >> >> > rc.right = rc.Width(); // [3]
>>> >> >> > rc.bottom = rc.Height(); // [4]
>>>
>>> >> >> ***
>>> >> >> This code is incorrect. You must not set the right and bottom in 
>>> >> >> this fashion, because
>>> >> >> you are working with the window rect, and the width and height are 
>>> >> >> independent of the
>>> >> >> coordinate system. Lose the two assignments above.
>>>
>>> >> >> > // translate into parents coordinates
>>> >> >> > ScreenToClient(hParent, &rc.TopLeft()); // [5]
>>>
>>> >> >> ****
>>> >> >> Why are you not doing something as simple as
>>> >> >> CRect rc;
>>> >> >> GetWindowRect(&rc);
>>> >> >> GetParent()->ScreenToClient(&rc);
>>> >> >> this is all you need. You have a complex and convoluted solution 
>>> >> >> to a simple problem.
>>> >> >> Just translating the top/left coordinate makes no sense, because 
>>> >> >> it will produce a window
>>> >> >> that has the wrong size.
>>>
>>> >> >no. everything works pretty well. i you insist, one could of course
>>> >> >define a struct RECT_ that has let, top, width and height members, 
>>> >> >but
>>> >> >apart from that, my way is completely ok.
>>>
>>> >> ****
>>> >> Why do you need to define a new structure? You can just do
>>> >> CRect rc;
>>> >> ::GetWindowRect(m_hWnd, &rc);
>>> >> ::ScreenToClient(parent, &rc);
>>> >> where, now that I know you are using multiple inheritance, is still 
>>> >> simpler than the
>>> >> complex code you wrote. And by setting the right and bottom to the 
>>> >> Width() and Height(),
>>> >> BEFORE transforming the top and left, you still get the wrong size.
>>> >> ****
>>>
>>> >�hm, no.. both rects are in pixel.
>>>
>>> ****
>>> Consider the following: the rect is in the more-or-less middle of the 
>>> screen, and
>>> somewhere inside of the window.
>>>
>>> Let the screen coordinates be 600,400, 700, 500, that is, it is a 
>>> 100x100 control
>>> physically at 600,400.
>>>
>>> You set rc.right=rc.Width() and rc.bottom=rc.Height(). So we have
>>> rc.right = 100;
>>> rc.bottom = 100;
>>>
>>> Let the (0,0) of the client area of the window that contains the control 
>>> be at 400, 200 in
>>> screen coordinates.
>>>
>>> Now we transform with ScreenToClient the initial coordinates, just top 
>>> and left, to client
>>> coordinates. In client coordinates, 600,400 translates to 200, 200 in 
>>> client coordinates.
>>> So you have a rectangle that starts at 200,200 and ends at 100,100, when 
>>> your goal is to
>>> have one that starts at 200,200 and goes to 300,300. Since right < left 
>>> and bottom < top,
>>> what you have is actually an illegal rectangle.
>>
>>in the view of "rectangle", you're right. but i have now something
>>different: i have struct that has x,y,width,height as needed by
>>CreateWindowEx(). but to dont make thinks to complicated for other i
>>now use the following struct:
>>
>>//-----------------------------------------------------------------------------
>>struct SQDim {
>> UINT nLeft;
>> UINT nTop;
>> UINT nWidth;
>> UINT nHeight;
>>
>> inline SQDim(UINT left = 0, UINT top = 0, UINT width = 0, UINT height
>>= 0) :
>> nLeft(left), nTop(top), nWidth(width), nHeight(height) {};
>>
>> inline SQDim const& operator =(SQDim const& rDim)
>> {memcpy(this, &rDim, sizeof(this));};
>>
>> inline SQDim const& operator =(RECT const& rRect)
>> {
>> nLeft   = rRect.left;
>> nTop    = rRect.top;
>> nWidth  = rRect.right  - nLeft;
>> nHeight = rRect.bottom - nTop;
>> };
>>
>> inline operator RECT() const
>> {RECT rc = {nLeft, nTop, nWidth + nLeft, nHeight + nTop}; return
>>rc;};
>>};
>>
>>>
>>> Had you just done ScreenToClient on the whole rectangle, you would have 
>>> gotten
>>> 200,200, 300, 300
>>> which is what you would want. right and bottom are not distances, but 
>>> absolute positions
>>> within the coordinate system in question, which in this case is the 
>>> client coordinate
>>> system (after translation). But you translate left and top as 
>>> coordinates and right and
>>> bottom as distances. This is erroneous.
>>> ****
>>>
>>> >> >> You have five overly complicated lines doing what two trivial 
>>> >> >> lines will accomplish.
>>> >> >> ****
>>>
>>> >> >> > // let derived class modify rc
>>> >> >> > OnCreationRect(rc);
>>>
>>> >> >> ****
>>> >> >> I have no idea what this does because there is no handler called 
>>> >> >> OnCreationRect and you
>>> >> >> have not given the code for this, but there's nothing I know that 
>>> >> >> needs to be done to this
>>> >> >> rectangle once you have it.
>>> >> >> ****
>>>
>>> >> >in this case, the derived class uses this virtual as following:
>>>
>>> >> >void CQComboBox::OnCreationRect(RECT& rc)
>>> >> >{
>>> >> > RECT rcDropped;
>>> >> > GetDroppedControlRect(&rcDropped);
>>> >> > rc.bottom = rcDropped.bottom - rcDropped.top;
>>> >> >}
>>>
>>> >> ****
>>> >> Using the 'On' prefix, which is used for handlers, is confusing. 
>>> >> Calling it something
>>> >> meaningful like ComputeDroppedRect might have made it less ambiguous 
>>> >> as to what was going
>>> >> on.
>>> >> ****
>>>
>>> >> >> > // create a new window at current windows coordinates
>>> >> >> > HWND hNew = CreateWindowEx(dwStyleEx, QGetClassName(), "", 
>>> >> >> > dwStyle,
>>> >> >> > rc.left, rc.top, rc.right, rc.bottom, hParent, 0,
>>> >> >> > ::AfxGetInstanceHandle(), NULL);
>>>
>>> >> >> ****
>>> >> >> Why are you using the raw CreateWindowEx call? You can do this 
>>> >> >> trivially in MFC:
>>>
>>> >> >> CWnd temp;
>>> >> >> temp.CreateEx(dwStyleEx, QGetClassName(), _T(""), dwStyle, rc,
>>> >> >> GetDlgCtrlId(), parent);
>>> >> >> Note how simple this is. For that matter, does CQControl have a 
>>> >> >> Create method that would
>>> >> >> be better?
>>>
>>> >> >> I have no idea why you have chosen to change the control ID by 
>>> >> >> setting it to 0; this kills
>>> >> >> off all your handlers in the parent window. For a brief moment you 
>>> >> >> will have two controls
>>> >> >> with the same ID, but this will be changed momentarily, and causes 
>>> >> >> no harm.
>>>
>>> >> >oh, i thought it was hMenu.
>>>
>>> >> ****
>>> >> Note that it is specified as being the hMenu for a top-level window 
>>> >> and the control ID for
>>> >> a child window. From the documentation:
>>>
>>> >> "For a child window, hMenu specifies the child-window identifer, an 
>>> >> integer value..."
>>>
>>> >> It will have to be cast to an HMENU to satisfy the compiler.
>>> >> joe
>>> >> ****
>>>
>>> >> >> But what you didn't do was make sure it is in the right place in 
>>> >> >> the Z-order
>>> >> >> temp.SetWindowPos(this, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
>>> >> >> DestroyWindow();
>>> >> >> Attach(temp.Detach());
>>>
>>> >> >> All this use of raw API and HWNDs is unneccessay.
>>> >> >> *****
>>>
>>> >> >> > // destroy old window and attach new one
>>> >> >> > DestroyWindow(pWnd->Detach());
>>> >> >> > pWnd->Attach(hNew);
>>> >> >> > m_hwnd = hNew;
>>>
>>> >> >> ****
>>> >> >> Get rid of all the above lines.
>>>
>>> >> >> The convoluted nature of what you are doing is probably what leads 
>>> >> >> to the assertion
>>> >> >> failure. I wouldn't even try to debug this code, I would rewrite 
>>> >> >> it as indicated. Then,
>>> >> >> and only then, if there is still a bug, would I worry about it.
>>>
>>> >> ****
>>> >> Since MFC does not normally support multiple inheritance, there can 
>>> >> be some confusing side
>>> >> effects here that may account for it. What is the type of the object 
>>> >> displayed by the
>>> >> debugger?
>>>
>>> >it displayes the expected type (CQComboBox)
>>>
>>> ****
>>> Then you should not be seeing the error. But, as I indicated, MFC does 
>>> not play well with
>>> multiple inheritance, and virtual destructors in a multiple inheritance 
>>> situation can have
>>> interesting consequences. You're off into uncharted territory here.
>>> ****
>>>
>>> >> Is there a reason you chose to use multiple inheritance over direct 
>>> >> inheritance? You are
>>> >> working in unsupported areas here.
>>>
>>> >of course;-) i have a baseclass (CQControl) from with CQButton,
>>> >CQTree, CQComboBox and so on derive. Each derived class uses multiple
>>> >inheritance to derive from CQControl and its MFC-class. By doind this,
>>> >i can do the following:
>>>
>>> >void SomeFunction(CQControl* pCtrl)
>>> >{
>>> > pCtrl->QResetContent();
>>> > // add an red blinking element with id ELEMENT_ID to the control
>>> > pCtrl->QElmSet(ELEMENT_ID, QDS_SHOWN|QDS_BLINK, DYE_RED);
>>> > // set text of element ELEMENT_ID with detail id DETAIL_ID to "Some
>>> >Text"
>>> > // and add an image
>>> > pCtrl->QDtlSet(ELEMENT_ID, DETAIL_ID, _T("Some Text"),
>>> >ELEMENT_IMAGE);
>>> > // Select element ELEMENT_ID
>>> > pCtrl->QSelectionSet(ELEMENT_ID);
>>> >}
>>>
>>> >if pCtrl is a CQListView, you set element-row ELEMENT_ID, detail-
>>> >column DETAIL_ID to image ELEMENT_IMAGE, detail DETAIL_ID. if pCtrl is
>>> >a CQButton and you have more than one element, you get a multibutton.
>>> >if you dont have "columns" (Button, ListBox,..), the details appear
>>> >tab-separated. So you have the same syntax for all controls. Use in
>>> >programm: guess you have a function that shall fill a selection-
>>> >control with user-names and some additional infos (an icon per user or
>>> >a user-state-color and so on). this function just gets a CQControl*
>>> >and fills it. if it fills a Listview, a Treeview, a ListBox, a
>>> >ComboBox or even a Button just depents on the design of the GUI. More:
>>> >CQControl uses a special worker thread and does all the syncronisation
>>> >needed, so you could call the above SomeFunction() from ANY Thread;-)
>>>
>>> ****
>>> Yes, it is a cool idea, but as I've indicated, you are out into 
>>> seriously uncharted
>>> territory here, and most of the ideas are not supported by the MFC 
>>> framework, which
>>> aggressively is single-inheritance.
>>>
>>> You can have the same syntax for all controls without requiring multiple 
>>> inheritance, but
>>> I agree it is painful to duplicate code. As far as I know, no one has 
>>> succeeded in doing
>>> this.
>>
>>
>>;-))))))))))))) What i wrote is no "i plan to do this". IT
>>WORKS! ;-)))
> ****
> It does?  I thought the whole point of this thread was that it doesn't. 
> It generates an
> error in the MFC runtime.  If it worked, you wouldn't have needed to post 
> the question...
> joe
> ****
>>
>>
>> I tried it myself some years ago for the same purposes, and after a
>>lot of
>>> newsgroup discussions, the verdict at that time was "You are never going 
>>> to win at this,
>>> don't bother", and I gave it up. Nothing has changed in the intervening 
>>> decade since I
>>> tried this, so it probably doesn't work today, either.
>>>
>>> It's not that you have a bad idea, but that you have an idea that is 
>>> probably incompatible
>>> with how MFC is designed to work.
>>> joe
>>> ****
>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newco...@flounder.com
>>> Web:http://www.flounder.com
>>> MVP Tips:http://www.flounder.com/mvp_tips.htm
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
dc2983 (3206)
11/12/2008 3:32:55 AM
Funny, I was just having that same thought as I was scrolling through to 
read the "thread" I gave up after about 8 chevrons in... :o)

Tom

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:%23P4GidHRJHA.1172@TK2MSFTNGP03.phx.gbl...
> I've nothing to add to this discussion, but do either of you believe in 
> snipping unused parts of the thread?  What a mess!  ;)
>
> -- David
>
> "Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
> news:e4bkh49irr6eenpsj2covms8l2ms2sq2pf@4ax.com...
>> See below...
>> On Tue, 11 Nov 2008 09:16:35 -0800 (PST), ".rhavin grobert" 
>> <clqrq@yahoo.de> wrote:
>>
>>>On 11 Nov., 17:42, Joseph M. Newcomer <newco...@flounder.com> wrote:
>>>> See below...
>>>>
>>>> On Tue, 11 Nov 2008 05:51:17 -0800 (PST), ".rhavin grobert" 
>>>> <cl...@yahoo.de> wrote:
>>>> >On 10 Nov., 20:43, Joseph M. Newcomer <newco...@flounder.com> wrote:
>>>> >> See below...
>>>> >> On Mon, 10 Nov 2008 10:26:29 -0800 (PST), ".rhavin grobert" 
>>>> >> <cl...@yahoo.de> wrote:

0
tom.nospam (3240)
11/12/2008 5:22:46 AM
On 12 Nov., 04:32, "David Ching" <d...@remove-this.dcsoft.com> wrote:
> I've nothing to add to this discussion, but do either of you believe in
> snipping unused parts of the thread? =A0What a mess! =A0;)
>
> -- David

And do you by chance know what TOFU is? ;)
0
clqrq (258)
11/12/2008 1:44:41 PM
On 12 Nov., 02:09, Joseph M. Newcomer <newco...@flounder.com> wrote:
> See below...
>

> >> You can have the same syntax for all controls without requiring multip=
le inheritance, but
> >> I agree it is painful to duplicate code. =A0As far as I know, no one h=
as succeeded in doing
> >> this.
>
> >;-))))))))))))) What i wrote is no "i plan to do this". IT
> >WORKS! ;-)))
>
> ****
> It does? =A0I thought the whole point of this thread was that it doesn't.=
 =A0It generates an
> error in the MFC runtime. =A0If it worked, you wouldn't have needed to po=
st the question...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joe
> ****

=F6hm, no. i posted a question regarding some small bug that leads to an
assert. if i set the needed flags at design time, all works pretty
well. Currently I have a slider, a button, a treeview, a listview, a
listbox and a combobox that all multiinheritantly derive from
CQControl and their mfc-class, can be controlled by the same commands,
have 64-bit identifiers and called from any thread and anywhere in the
program. works in debug and release, tested on XP, Win2k and Win98.
Every element, detail and control suports the following style-flags,
including a native blinking-mode and a "glass-look" (line Vista, but
IMAO better looking):

//---------------------------------------------------------------------
// Detail, Element and Object States
#define QDS_SELECTED     ODS_SELECTED /* 0x00000001 */
#define QDS_GRAYED       ODS_GRAYED   /* 0x00000002 */
#define QDS_DISABLED     ODS_DISABLED /* 0x00000004 */
#define QDS_CHECKED      ODS_CHECKED  /* 0x00000008 */
#define QDS_FOCUS        ODS_FOCUS    /* 0x00000010 */
#define QDS_DEFAULT      ODS_DEFAULT  /* 0x00000020 */
#define QDS_HOVER     /* ODS_HOTLIGHT */ 0x00000040
#define QDS_INACTIVE  /* ODS_INACTIVE */ 0x00000080
#define QDS_BLINKING                     0x00000100
#define QDS_LIT                          0x00000200
#define QDS_ANTIBLINK  ( QDS_BLINKING | QDS_LIT )
#define QDS_PRESSED                      0x00000400
#define QDS_CUT                          0x00000800
#define QDS_DROPHILIGHT                  0x00001000
#define QDS_GHOSTY                       0x00002000
#define QDS_BOLD                         0x00004000
#define QDS_SUNKEN                       0x00008000
#define QDS_BORDER                       0x00010000

#define QDS_STYLEMASK                    0x00300000
#define QDS_SIMPLE                       0x00000000
#define QDS_FLAT                         0x00100000
#define QDS_TILE                         0x00200000
#define QDS_GLASS                        0x00300000
0
clqrq (258)
11/12/2008 1:55:45 PM
".rhavin grobert" <clqrq@yahoo.de> wrote in message 
news:219954f1-c41c-4ec4-804a-dead99e746ca@e1g2000pra.googlegroups.com...
>
> And do you by chance know what TOFU is? ;)


Um, soft white bean curd?  ;)  Anyway, as long as you and Joe are extracting 
the relevant info, that's the main thing, although I would like to follow 
along.  Thanks for snipping your last post.  Much easier!  :-)

-- David 

0
dc2983 (3206)
11/12/2008 2:17:52 PM
Reply:

Similar Artilces:

windows media player extension
As I browse some websites they request that I download the windows media player extension. This is puzzling since my version of windows 7 has windows media player 12. Perhaps what is being referred to is an addon for IE 8, eh. If so, then couild someone forward me a link so that I can download the proper addon directly from the microsoft website please. Hi tang, Do you know which web sites? We can check if the sites are detecting your latest version of WMP correctly. It may just be incorrect programming at these sites. Regards. "tangbeili" <tangbei...

Hardware Monitor Windows Xp
Hi i own a sony vio windows xp desktop.I've owned this computer for about 8 years and recently for the last two years i have been getting a hardware monitor error everytime i boot up. I was wondering if anyone would b able to help me fix this problem. Thank You. simon978 wrote on Fri, 11 Dec 2009 12:46:18 -0600: > Hi i own a sony vio windows xp desktop.I've owned this computer for > about 8 years and recently for the last two years i have been getting a > hardware monitor error everytime i boot up. I was wondering if anyone > would b able to help me fix this ...

Restore mail databases after Windows reinstall
Had to reformat/reinstall Windows 98 and Outlook Express 6 this week. I have all my old e-mail, stored in *.dbx files from before the reformat. I can't get OE6 to see these files. The Microsoft Knowledge Base (Q283205) tells how to restore these folders with OE 5.0, but the option listed there ("Import mail from an OE store directory") does not exist in OE6. How do I restore these *.dbx files? Thanks! Scott Crawford <anonymous@discussions.microsoft.com> wrote: > Had to reformat/reinstall Windows 98 and Outlook Express 6 > this week. > > I have all m...

Windows 7 newsgroup?
I can't find a Windows 7 newsgroup on this server. Am I missing something? Thank you. Herbert Eppel www.HETranslation.co.uk There isn't one. Windows 7 forums http://social.technet.microsoft.com/Forums/en/category/w7itpro/ "Herbert Eppel" <HE@UK> wrote in message news:%23AMaz1c1KHA.5972@TK2MSFTNGP06.phx.gbl... :I can't find a Windows 7 newsgroup on this server. : : Am I missing something? : : Thank you. : : Herbert Eppel : www.HETranslation.co.uk Thanks for your quick reply and the forum link. Pity there isn't a newsgroup, whi...

Recreate Chart of accounts
We created the chart of accounts for a new company and there are a few transactions went through and posted. Then later we designed to change the segments of the GL accounts. That means a new set of COA is needed. The transactions posted is not a concern for us and they can be reentered. But GP won't allow us to delete if posted transactions exist. Is there any way to delete the old set of COA? Thanks! In the same company you would need to purge the history and reconcile to clear the account summaries. Alternatively, you could create a new company and copy the setup to it, if there'...

Is it wise to upgrade from Windows Vista to Windows 7?
What are the pros and cons of Windows 7 -- Kristen Rios On Tue, 16 Mar 2010 12:55:02 -0700, PPatty89 <Firefightersrule89@yahoo.com> wrote: > What are the pros and cons of Windows 7 We all have different opinions, and see different things as pros and different things as cons. Here's my standard reply to questions like this: My view is that you're going about this backward. A change of operating system should be driven by need, not just because there is a new version available. Are you having a problem with Windows XP or Vista (whichever you use) that you...

Windows Mail
Some files cannot be sent out even though I have timer sent for outgoing mail at five minutes. The outing blue bar moves real slow and when it gets about three quarters for finishing it stops and says server stopped working. What is the size of this file? Please post the error message verbatim. -- Bruce Hagen MS-MVP [Mail] Imperial Beach, CA "Walter Chimack" <WalterChimack@discussions.microsoft.com> wrote in message news:B7248DDC-9599-47AD-8447-482203F6C2D7@microsoft.com... > Some files cannot be sent out even though I have timer...

recreate a window
a CComboBox and CQControl derived control shall recreate itself, if the styles given in resource not match the style required for toe control (here: CBS_OWNERDRAWFIXED must be set). As CComboBox is unable to correctly modify this style with ModifyStyle(), the recreation is called and works. ____________________________________________ //----------------------------------------------------------------------- // recreate the underlying hwnd to match required styles bool CQControl::QRecreateWindow(DWORD dwStyle, DWORD dwStyleEx) { CWnd* pWnd = CWnd::FromHandlePermanent(m_hwnd); ASSERT(pWnd != ...

How do I Recreate Schedule+ Free Busy public folder
Had 2 Exchange 5.5 servers. Was in the process of a migration. The first, primary, Exchange server crashed. Having problems restoring databases. New server works fine, but continually receive Unable to update public free/busy data. The contents of this public folder are currently unavailable. The Schedule+ Free Busy public folder was not replicated to the new server. Is there a way to create it on the new server since the first, primary, server is unavailable. Thanks ...

How to make printed name badges in Windows?
Trying to make a custom name badge with photo and pic for reunion. Can anyone help? See http://www.gmayor.com/graphics_on_labels.htm and/or http://www.gmayor.com/mail_merge_graphics.htm -- <>>< ><<> ><<> <>>< ><<> <>>< <>><<> Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org <>>< ><<> ><<> <>>< ><<> <>>< <>><<> "Picesdreamer" <Picesdreamer@...

Windows Mail
How can I undo a mail rule that I made in Windows Mail? Thank you. Tools | Message Rules | Mail. Uncheck or remove the rule. -- Bruce Hagen MS-MVP [Mail] Imperial Beach, CA "melizabeth" <elizabet98_98@yahoo.com> wrote in message news:ud$V$ZsyKHA.5040@TK2MSFTNGP02.phx.gbl... > How can I undo a mail rule that I made in Windows Mail? > > Thank you. Perfect - Worked like a charm... Thanks Bruce. "Bruce Hagen" <BRH@nospam.invalid> wrote in message news:%23ODtjdsyKHA.5940@TK2MSFTNGP02.phx.gbl... >...

outlook/windows mail 08-15-10
I have a scanner and want to scan docs and send as attachments. I have Vista on my laptop and when I go to attach outlook pops up not windows mail. The attachment will not send as I do not use outlook. I have already set the default programs to Windows mail. Some scanners are hard-coded to use Outlook, but try this: Your Windows Mail may not have all its defaults assigned. Open the Default Programs applet, which you can access either from the Start menu or via the Control Panel, then click the first item: "Set your default programs." After a few seconds, a list of pro...

Windows 7 Discussion Group
Is there one? If so and I missed it I apologize. Thanks "RHinNC" <rhinnc@[get rid of this] hotmail.com> wrote in message news:OEORv3yhKHA.5604@TK2MSFTNGP04.phx.gbl... > Is there one? If so and I missed it I apologize. Thanks > There are Microsoft forums, but no Microsoft newsgroups. There is an alt.windows7.general newsgroup, though, if your ISP carries it. -- SC Tom On 12/27/2009 2:51 PM, RHinNC wrote: > Is there one? If so and I missed it I apologize. Thanks > > I have been using the alt.windows7.general which is available a free...

Windows Gadgets
I am running Win 7 Pro 64 and Have found that none of the game gadgets work on my system. Is this because I'm running 64 bit and they are made for 32 bit or is something else the problem? "Daves Spam" <dmathews9587@comcast.net> wrote in message news:O1Ooq4gILHA.1868@TK2MSFTNGP05.phx.gbl... > I am running Win 7 Pro 64 and Have found that none of the game gadgets > work on my system. Is this because I'm running 64 bit and they are made > for 32 bit or is something else the problem? 32 bit gadgets will work with 64 bit Windows, you must have...

Windows 7 64bit unable to update
Hi, I have installed Windows 7 64bit and now I find windows will not update. It says it has updates, it sahows me the list and I select what I want updated (usually all), and the green bar says it is Downloading updates (0%.... and never does! It will not download any updates, no errors, just goes of into cyber space. Similar, also 7 64bit, only mine reached the installation of the 6th of 6 updates, and has hung there for hours. I attempted to restart, and it is not in the shut down faze, still reporting installation of the last update....

Windows Server 2003 Shadow Copy Client
Is there a way to restore shadow copies from the server? Thnaks > Is there a way to restore shadow copies from the server? to where? DDS "Todd Heiks" <Todd.Heiks_AT_NoSpam_GreatLakesWindow.com> wrote in message news:exffSpCdKHA.2188@TK2MSFTNGP04.phx.gbl... > Is there a way to restore shadow copies from the server? > > Thnaks > Answer: navigate to file via the share eg. \\server\share\file.name "Todd Heiks" <Todd.Heiks_AT_NoSpam_GreatLakesWindow.com> wrote in message news:exffSpCdKHA.2188@TK2MSFTNGP04.ph...

Flagging
I did something stupid and now I am in the soup. My boss's boss called me while he was traveling on business to check his e-mail messages because his assistant was out to lunch. When I opened his mailbox he had literaly 15 of those pesky flagged message pop-up reminders. I dismissed them because I find them annoying and wanted to get to his messages. It turns out those pesky reminders are a valuable mnemonic device for him. How do I restore the active pop-up messages without changing the original due date? He wants the original action date to remain. When I try to put in b...

SBS2003 R2 with Windows 7 Pro
Not tried connecting Windows 7 Pro to SBS 2003 ... I've just been given 4 new Windows 7 Notebooks to setup for new employeed (One of the directors has just ordered 4 Dell Notebooks with Windows 7 while I was on Holiday) Is this a question of just running connect computer? On Tue, 31 Aug 2010 10:18:07 +0100, "JohnB" <JohnB@msforums.com> wrote: >Not tried connecting Windows 7 Pro to SBS 2003 ... > >I've just been given 4 new Windows 7 Notebooks to setup for new employeed >(One of the directors has just ordered 4 Dell Notebooks with Wind...

Excel 2007 Suppress "bell ringing" when switching windows??
When I switch from sheet to sheet, a bell rings. It's very annoying. How can I stop this in Excel 2007? Thank you To select or clear specific sounds On the Start menu, point to Settings, click Control Panel, and then double-click the Sounds and Multimedia icon. In the Sound Events list, scroll down to Microsoft Office, and select the sound you wish to turn on or off. Adjust the volume by sliding the Volume bar. Click OK. Brad wrote: > When I switch from sheet to sheet, a bell rings. It's very annoying. > How can I stop this in Excel 2007? > > Thank you On May 2...

Whew, I have updated themes to Windows Classic for Windows Vista
I have finally gotten around to hooking up my 17inch monitor to use for my laptop. In addition, I have updated all themes and toolbars to Windows Classic Theme so I feel much more at home. Next step is to get a real external USB keyboard and real external USB Mouse for Vista so I can make it like a desktop replacement while I wait for the motherboard for my desktop. ...

Recreate CRM Administrator account?
One of my customers deleted the AD account that installed CRM (hence the CRM system admin). Is there anyway to recreate or create an account witht he same rights in CRM? CRM 3.0 fully patched. Thanks -- Fliehigh Can't you just re-create the AD account with the same name as the old one? "Fliehigh" wrote: > One of my customers deleted the AD account that installed CRM (hence the CRM > system admin). > > Is there anyway to recreate or create an account witht he same rights in CRM? > > CRM 3.0 fully patched. > > Thanks > > -- > Fli...

SetWindowRgn make window lost XP Window Style
I have a main window that I want to cut a square hole out of a standard window. I use standard region API calls and this works fine. However, I find that whenever I use SetWindowRgn, I lose the "Windows XP" look of the main window - ie. the window reverts to "Windows Classic" appearance, without the rounded title bar and blue frame. Is this avoidable? Ideally, I'd like to keep the XP window look when using my app in XP. I call SetWindowRgn in OnSize function. Has anyone help come across this and have a solution? Thanks in advance to anyone who can...

How to save a color to palette without recreating it. (Word, 2002)
I'm doing a Table and each cell has one of four background colors. They are not on the default "Fill Colors", so I have to go in and reselect the RGB each time. How can I put the color on the palette? Or is there another way to save it so all I have to do is click on it when I need that color? On Mon, 18 Jan 2010 14:49:01 -0800, b4a5s <b4a5s@discussions.microsoft.com> wrote: >I'm doing a Table and each cell has one of four background colors. They are >not on the default "Fill Colors", so I have to go in and reselect the RGB >each...

OT: Windows 7 (XP with a new look!)
What a heap of crap, ...not just Windows 7 but, also the Asus X5DIJ laptop that I just bought for my Aunty !!! Having just finished a late shift at work, I thought I'd run the Asus "Recovery Disc Creation" procedure, (Laptop arrived this morning, just before I had to go to work), so that it gets done. ....ready for when I take it in to her tommorrow morning. The supplied "AI Recovery" has been running for over 45 minutes, first creating a backup image, then ISO files, ....then it finally burnt the 1st ISO image to DVD+r ...or they may be -r' disc...

Identify the windows just below the menu
I am writing instructions for non-users of excel and need to identify the windows just below the menu. specifically the one that identifies what cell is ready for data. the one that indicates the name of the selected data for sorting purposes (just above cell A1. It's called the name box. -- Biff Microsoft Excel MVP "Luismo" <Luismo@discussions.microsoft.com> wrote in message news:C684F246-F075-41AB-8128-2B23E8AD6985@microsoft.com... >I am writing instructions for non-users of excel and need to identify the > windows just below the menu. specifi...