GetItemText returns bad CString & can't change subitem color in CustomDraw
-
I am attempting to write a CListCtrl with CustomDraw for PocketPC 2002 in Embedded C++ 3.0. I hoped to have the list control handle custom draw messages (to display red text for negative numbers) so three dialogs could benefit. Have found that ON_NOTIFY_REFLECT messages never arrive in the control. Brad Spencer at Group1 Software verified that list controls don't receive custom draw events. I began catching NOTIFY messages in the dialog and directly handing them off to a custom draw message handler in the control. The handler code follows below: The PosDialog transfers control to a public function of the control which hands the call to a (protected) custom draw message handler. ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) void CPosDialog::OnCustDrwPosLst( NMHDR* pNMHDR, LRESULT* pResult ) { CRBListCtrl* pLC = (CRBListCtrl*)this->GetDlgItem( IDC_PosList ); pLC->ReflectCustomDraw( pNMHDR, pResult ); } The control passes control to a handler written to respond to ON_NOTIFY_REFLECT messages (which never arrive). In the control's .h file: public: void ReflectCustomDraw( NMHDR* pNMHDR, LRESULT* pResult ) { OnCustomDraw( pNMHDR, pResult); }; and its .cpp file: ON_NOTIFY_REFLECT( NM_CUSTOMDRAW, OnCustomDraw ) void CRBListCtrl::OnCustomDraw( NMHDR* pNMHDR, LRESULT* pResult ) { NMLVCUSTOMDRAW* pCustomDraw = (NMLVCUSTOMDRAW*)pNMHDR; NMCUSTOMDRAW nmcd = pCustomDraw->nmcd; int rr = nmcd.dwItemSpec; DWORD drawStage = nmcd.dwDrawStage; switch ( drawStage ) { case CDDS_PREPAINT: *pResult = CDRF_NOTIFYITEMDRAW; break; case CDDS_ITEMPREPAINT: *pResult = CDRF_NOTIFYSUBITEMDRAW; break; case CDDS_ITEMPREPAINT | CDDS_SUBITEM: { // which subitem? int si = pCustomDraw->iSubItem; CString cst = GetItemText( rr, si ); bool red = (cst[0] == '-'); //access violation CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( red ? RGB(255,0,0) : RGB(0,0,0) ); *pResult = CDRF_NOTIFYPOSTPAINT; break; } case CDDS_ITEMPOSTPAINT | CDDS_SUBITEM: { CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( RGB(0,0,0) ); *pResult = CDRF_DODEFAULT; break; } default: break; } } GetItemText() above returns a CString which (if accessed) will produce a memory access violation. The other possibly relevant code is functionally identical to Mike Blazczak's AddPool() on p. 443 of "MFC with Visual C++ 6", excerpted here: LPTSTR CPosDialog::AddPool( CString* cst ) { CString& nxCStr = cstPool[ nextFreeSlo
-
I am attempting to write a CListCtrl with CustomDraw for PocketPC 2002 in Embedded C++ 3.0. I hoped to have the list control handle custom draw messages (to display red text for negative numbers) so three dialogs could benefit. Have found that ON_NOTIFY_REFLECT messages never arrive in the control. Brad Spencer at Group1 Software verified that list controls don't receive custom draw events. I began catching NOTIFY messages in the dialog and directly handing them off to a custom draw message handler in the control. The handler code follows below: The PosDialog transfers control to a public function of the control which hands the call to a (protected) custom draw message handler. ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) void CPosDialog::OnCustDrwPosLst( NMHDR* pNMHDR, LRESULT* pResult ) { CRBListCtrl* pLC = (CRBListCtrl*)this->GetDlgItem( IDC_PosList ); pLC->ReflectCustomDraw( pNMHDR, pResult ); } The control passes control to a handler written to respond to ON_NOTIFY_REFLECT messages (which never arrive). In the control's .h file: public: void ReflectCustomDraw( NMHDR* pNMHDR, LRESULT* pResult ) { OnCustomDraw( pNMHDR, pResult); }; and its .cpp file: ON_NOTIFY_REFLECT( NM_CUSTOMDRAW, OnCustomDraw ) void CRBListCtrl::OnCustomDraw( NMHDR* pNMHDR, LRESULT* pResult ) { NMLVCUSTOMDRAW* pCustomDraw = (NMLVCUSTOMDRAW*)pNMHDR; NMCUSTOMDRAW nmcd = pCustomDraw->nmcd; int rr = nmcd.dwItemSpec; DWORD drawStage = nmcd.dwDrawStage; switch ( drawStage ) { case CDDS_PREPAINT: *pResult = CDRF_NOTIFYITEMDRAW; break; case CDDS_ITEMPREPAINT: *pResult = CDRF_NOTIFYSUBITEMDRAW; break; case CDDS_ITEMPREPAINT | CDDS_SUBITEM: { // which subitem? int si = pCustomDraw->iSubItem; CString cst = GetItemText( rr, si ); bool red = (cst[0] == '-'); //access violation CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( red ? RGB(255,0,0) : RGB(0,0,0) ); *pResult = CDRF_NOTIFYPOSTPAINT; break; } case CDDS_ITEMPOSTPAINT | CDDS_SUBITEM: { CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( RGB(0,0,0) ); *pResult = CDRF_DODEFAULT; break; } default: break; } } GetItemText() above returns a CString which (if accessed) will produce a memory access violation. The other possibly relevant code is functionally identical to Mike Blazczak's AddPool() on p. 443 of "MFC with Visual C++ 6", excerpted here: LPTSTR CPosDialog::AddPool( CString* cst ) { CString& nxCStr = cstPool[ nextFreeSlo
Try to check control HWND/id before calling ReflectCustomDraw in CPosDialog::OnCustDrwPosLst. I guess there are some other controls and you're just calling ReflectCustomDraw too often. In other words, ReflectCustomDraw tries to handle message targeted to other window. BTW: I have eVC 3.0 app here, and reflected NM_CUSTOMDRAW works perfectly for CListCtrl without hacks like OnCustDrwPosLst. But then, I host them in CPropertyPage-derived class. Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
-
Try to check control HWND/id before calling ReflectCustomDraw in CPosDialog::OnCustDrwPosLst. I guess there are some other controls and you're just calling ReflectCustomDraw too often. In other words, ReflectCustomDraw tries to handle message targeted to other window. BTW: I have eVC 3.0 app here, and reflected NM_CUSTOMDRAW works perfectly for CListCtrl without hacks like OnCustDrwPosLst. But then, I host them in CPropertyPage-derived class. Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
Tom, I appreciate the fast reply, but I'm fairly certain the dialog's ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) effectively filters out messages meant for controls other than PosList. When I get PosList messages in the debugger, the other controls seem to have finished painting, though the list control is the only one listening for CustomDraw messages. View derived classes apparently get their CustomDraw messages and (from what I can tell) CtrlList derived classes get REFLECTed CustomDraw messages on other targets, but CtrlLists on PocletPC 2002 don't get notified without the hack. Possibly comctl32 builds are customized per target. I'd love not to have the hack, but at this point, I just want GetItemText to stop crashing and subitem text to paint red when I tell it to. -Mike Landis
-
Tom, I appreciate the fast reply, but I'm fairly certain the dialog's ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) effectively filters out messages meant for controls other than PosList. When I get PosList messages in the debugger, the other controls seem to have finished painting, though the list control is the only one listening for CustomDraw messages. View derived classes apparently get their CustomDraw messages and (from what I can tell) CtrlList derived classes get REFLECTed CustomDraw messages on other targets, but CtrlLists on PocletPC 2002 don't get notified without the hack. Possibly comctl32 builds are customized per target. I'd love not to have the hack, but at this point, I just want GetItemText to stop crashing and subitem text to paint red when I tell it to. -Mike Landis
Mike Landis wrote: appreciate the fast reply, but I'm fairly certain the dialog's ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) effectively filters out messages meant for controls other than PosList Yes, I realized this right after posting the reply. Just to be 102% sure, check if you don't have duplicate control IDs in your dialog. This would screw notification routing. At this point, I'd resort to basic debugging tricks. What are the contents of pCustomDraw structure - are members looking 'normally' or rather it's random data? Also, according to comments in the code your program crashes when you're accessing the 0th element of the string. Maybe GetItemText returns empty one? Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
-
Tom, I appreciate the fast reply, but I'm fairly certain the dialog's ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) effectively filters out messages meant for controls other than PosList. When I get PosList messages in the debugger, the other controls seem to have finished painting, though the list control is the only one listening for CustomDraw messages. View derived classes apparently get their CustomDraw messages and (from what I can tell) CtrlList derived classes get REFLECTed CustomDraw messages on other targets, but CtrlLists on PocletPC 2002 don't get notified without the hack. Possibly comctl32 builds are customized per target. I'd love not to have the hack, but at this point, I just want GetItemText to stop crashing and subitem text to paint red when I tell it to. -Mike Landis
BTW, I have just noticed that you're casting CWnd* returned from GetDlgItem to CListCtrl-derived class. This may also contribute to your problem. Usually, one would have a dialog member represeting list control, connected to actual HWND with SubclassDlgItem or DDX_Control. Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
-
Mike Landis wrote: appreciate the fast reply, but I'm fairly certain the dialog's ON_NOTIFY( NM_CUSTOMDRAW, IDC_PosList, OnCustDrwPosLst ) effectively filters out messages meant for controls other than PosList Yes, I realized this right after posting the reply. Just to be 102% sure, check if you don't have duplicate control IDs in your dialog. This would screw notification routing. At this point, I'd resort to basic debugging tricks. What are the contents of pCustomDraw structure - are members looking 'normally' or rather it's random data? Also, according to comments in the code your program crashes when you're accessing the 0th element of the string. Maybe GetItemText returns empty one? Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
I don't think eVC 3.0 will load the resource file if you have conflicting IDs in the same dialog (I've had to fix this after hand editing the resource files before). I have hundreds of calls where I cast from CWnd* to a *Ctrl of some sort - the eVC3 documentation for CWnd::GetDlgItem says: This method retrieves a pointer to the specified control or child window in a dialog box or other window. The pointer returned is usually cast to the type of control identified by nID. The struct pointed to by pCustomDraw looks normal as does the nmcd struct. You're absolutely right that GetItemTxt() could be returning an empty string. Its returning an empty string for every subitem in the list control. Why would that happen? The following: if ( cst.GetLength() > 0 ) { bool red = ( cst[0] == '-' ); CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( red ? RGB(255,0,0) : RGB(0,0,0) ); } prevents access violations, but doesn't explain why cst comes back "" for every subitem. In watching the code that responds to the LVN_GETDISPINFO messages to the PosListCtrl just before the CustomDraw messages come in, I can see normal looking CString values coming out of the LVN_GETDISPINFO handler: void CSPosDialog::OnGetDispInfoPosList( NMHDR* pNMHDR, LRESULT* pResult ) { LV_DISPINFO* pDispInfo = (LV_DISPINFO*)pNMHDR; if ( pDispInfo->item.mask & LVIF_TEXT ) { SPosListItemInfo* pItem = (SPosListItemInfo*) pDispInfo->item.lParam; CString cst = this->GetPosItemText( pDispInfo->item.iItem, pDispInfo->item.iSubItem ); LPTSTR pBuf = this->AddPool( &cst ); pDispInfo->item.pszText = pBuf; } *pResult = 0; } CString CSPosDialog::GetPosItemText( int rr, int si ) { // get the sortCol for this subitem CBOSListCtrl* pLC = (CBOSListCtrl*)this->GetDlgItem( IDC_PosList ); short msi = pLC->MapSubitem( si ); // column reordering CHeaderCtrl* pHdr = pLC->GetHeaderCtrl(); short nItems = pHdr->GetItemCount(); if ( msi < 0 || msi >= nItems-1 ) return _T(""); SPosListItemInfo* pItem = (SPosListItemInfo*)pLC->GetItemData( rr ); if ( !pItem ) return _T(""); // impossible CPos* pos = pItem->thePos; bool itsTheTotalRow = ( pos == 0 ); double res; if ( msi == 8 ) return itsTheTotalRow ? _T("") : pos->note; unsigned short buf[20]; switch ( msi ) { case 0: swprintf( buf, "first col ..." ); // ... case 7: swprintf( buf, "other ..." );
-
I don't think eVC 3.0 will load the resource file if you have conflicting IDs in the same dialog (I've had to fix this after hand editing the resource files before). I have hundreds of calls where I cast from CWnd* to a *Ctrl of some sort - the eVC3 documentation for CWnd::GetDlgItem says: This method retrieves a pointer to the specified control or child window in a dialog box or other window. The pointer returned is usually cast to the type of control identified by nID. The struct pointed to by pCustomDraw looks normal as does the nmcd struct. You're absolutely right that GetItemTxt() could be returning an empty string. Its returning an empty string for every subitem in the list control. Why would that happen? The following: if ( cst.GetLength() > 0 ) { bool red = ( cst[0] == '-' ); CDC* dc = CDC::FromHandle( nmcd.hdc ); dc->SetTextColor( red ? RGB(255,0,0) : RGB(0,0,0) ); } prevents access violations, but doesn't explain why cst comes back "" for every subitem. In watching the code that responds to the LVN_GETDISPINFO messages to the PosListCtrl just before the CustomDraw messages come in, I can see normal looking CString values coming out of the LVN_GETDISPINFO handler: void CSPosDialog::OnGetDispInfoPosList( NMHDR* pNMHDR, LRESULT* pResult ) { LV_DISPINFO* pDispInfo = (LV_DISPINFO*)pNMHDR; if ( pDispInfo->item.mask & LVIF_TEXT ) { SPosListItemInfo* pItem = (SPosListItemInfo*) pDispInfo->item.lParam; CString cst = this->GetPosItemText( pDispInfo->item.iItem, pDispInfo->item.iSubItem ); LPTSTR pBuf = this->AddPool( &cst ); pDispInfo->item.pszText = pBuf; } *pResult = 0; } CString CSPosDialog::GetPosItemText( int rr, int si ) { // get the sortCol for this subitem CBOSListCtrl* pLC = (CBOSListCtrl*)this->GetDlgItem( IDC_PosList ); short msi = pLC->MapSubitem( si ); // column reordering CHeaderCtrl* pHdr = pLC->GetHeaderCtrl(); short nItems = pHdr->GetItemCount(); if ( msi < 0 || msi >= nItems-1 ) return _T(""); SPosListItemInfo* pItem = (SPosListItemInfo*)pLC->GetItemData( rr ); if ( !pItem ) return _T(""); // impossible CPos* pos = pItem->thePos; bool itsTheTotalRow = ( pos == 0 ); double res; if ( msi == 8 ) return itsTheTotalRow ? _T("") : pos->note; unsigned short buf[20]; switch ( msi ) { case 0: swprintf( buf, "first col ..." ); // ... case 7: swprintf( buf, "other ..." );
Mike Landis wrote: I have hundreds of calls where I cast from CWnd* to a *Ctrl of some sort - the eVC3 documentation for CWnd::GetDlgItem says: This method retrieves a pointer to the specified control or child window in a dialog box or other window. The pointer returned is usually cast to the type of control identified by nID. Well, this allows you to call wrapper methods which basically use SendMessage to expose Win32 control functionality. I'm assuming there's no associated MFC object and GetDlgItem returns temporary CWnd *. In such case you can't also use message reflection - this could contribute to your problems with NM_CUSTOMDRAW not passing through. Anyway, the problem obviously lies in AddPool and/or related functions. I can't really comment on this, because parts of the code implementing pool are missing. I guess you should put the breakpoint in OnGetDispInfoList, in the line where pszText is actually set. You may also use TRACE to check if LVN_GETDISPINFO is handled correctly. Wrt to changed text color - you should change the clrText member instead of using SetTextColor. Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
-
Mike Landis wrote: I have hundreds of calls where I cast from CWnd* to a *Ctrl of some sort - the eVC3 documentation for CWnd::GetDlgItem says: This method retrieves a pointer to the specified control or child window in a dialog box or other window. The pointer returned is usually cast to the type of control identified by nID. Well, this allows you to call wrapper methods which basically use SendMessage to expose Win32 control functionality. I'm assuming there's no associated MFC object and GetDlgItem returns temporary CWnd *. In such case you can't also use message reflection - this could contribute to your problems with NM_CUSTOMDRAW not passing through. Anyway, the problem obviously lies in AddPool and/or related functions. I can't really comment on this, because parts of the code implementing pool are missing. I guess you should put the breakpoint in OnGetDispInfoList, in the line where pszText is actually set. You may also use TRACE to check if LVN_GETDISPINFO is handled correctly. Wrt to changed text color - you should change the clrText member instead of using SetTextColor. Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
There are real MFC objects behind the GetDlgItem call, so I think the CWnd*s are real. I use the (cast)ptrs to call CCtrlList, CEdit, etc. functions. I'm not wrapping anything, just subclassing, so I hope I haven't killed NM_CUSTOMDRAW passthrough. The reason I don't suspect OnGetDispInfoList() is because the control behaves quite rationally in all other cases. I can scroll the view generating update events and it handily fetches the right stuff from OnGetDispInfoList() and displays it in the control. The only other code I know is: const unsigned short StringPoolSize = 3; unsigned short nextFreeSlot; CString cstPool[StringPoolSize ]; LPTSTR pBufPool[StringPoolSize ]; from the PosDialog's .h file and GetItemText in the ListCtrl itself, excerpted here: CString CListCtrl::GetItemText(int nItem, int nSubItem) const { ASSERT(::IsWindow(m_hWnd)); LVITEM lvi; memset(&lvi, 0, sizeof(LVITEM)); lvi.iSubItem = nSubItem; CString str; int nLen = 128; int nRes; do { nLen *= 2; lvi.cchTextMax = nLen; lvi.pszText = str.GetBufferSetLength(nLen); nRes = (int)::SendMessage(m_hWnd, LVM_GETITEMTEXT, (WPARAM)nItem, (LPARAM)&lvi); } while (nRes == nLen-1); str.ReleaseBuffer(); return str; } The chain of events is: the CustomDraw handler calls GetItemText which sends a LVM_GETITEMTEXT message, received by GetDispInfoPosList which puts the CString in the pool (calls AddPool). AddPool plays with the reference count so the CString can't be released and sends back its pool copy. The LPTSTR retVal also looks good every time and its still okay when pDispInfo->item.pszText is assigned in OnGetDispInfoPosList(). Then you're back in _AfxDispatchCmdMsg (which can hardly be screwed up). str still shows the correct value after ReleaseBuffer in GetItemText and is good when you are at the final brace. The next thing you know, you're in OnCustomDraw and the string is gone. Apparently ReleaseBuffer decrements the reference count to 0 and the string goes away when the stack unrolls. Thinking that Blazczak's pooling didn't anticipate CustomDraw calling GetItemText(), ultimately leading to one ReleaseBuffer() call he hadn't anticipated, I tried setting: const unsigned short StringPoolSize = 4; in the PosDialog's .h file and modifying the circular indexing in AddPool to use StringPoolSize (instead of 3), so it now reads: if ( ++nextFreeSlot > StringPoolSize-1 ) nextFreeSlot = 0; No change was evident. As soon as you return from GetItemText
-
There are real MFC objects behind the GetDlgItem call, so I think the CWnd*s are real. I use the (cast)ptrs to call CCtrlList, CEdit, etc. functions. I'm not wrapping anything, just subclassing, so I hope I haven't killed NM_CUSTOMDRAW passthrough. The reason I don't suspect OnGetDispInfoList() is because the control behaves quite rationally in all other cases. I can scroll the view generating update events and it handily fetches the right stuff from OnGetDispInfoList() and displays it in the control. The only other code I know is: const unsigned short StringPoolSize = 3; unsigned short nextFreeSlot; CString cstPool[StringPoolSize ]; LPTSTR pBufPool[StringPoolSize ]; from the PosDialog's .h file and GetItemText in the ListCtrl itself, excerpted here: CString CListCtrl::GetItemText(int nItem, int nSubItem) const { ASSERT(::IsWindow(m_hWnd)); LVITEM lvi; memset(&lvi, 0, sizeof(LVITEM)); lvi.iSubItem = nSubItem; CString str; int nLen = 128; int nRes; do { nLen *= 2; lvi.cchTextMax = nLen; lvi.pszText = str.GetBufferSetLength(nLen); nRes = (int)::SendMessage(m_hWnd, LVM_GETITEMTEXT, (WPARAM)nItem, (LPARAM)&lvi); } while (nRes == nLen-1); str.ReleaseBuffer(); return str; } The chain of events is: the CustomDraw handler calls GetItemText which sends a LVM_GETITEMTEXT message, received by GetDispInfoPosList which puts the CString in the pool (calls AddPool). AddPool plays with the reference count so the CString can't be released and sends back its pool copy. The LPTSTR retVal also looks good every time and its still okay when pDispInfo->item.pszText is assigned in OnGetDispInfoPosList(). Then you're back in _AfxDispatchCmdMsg (which can hardly be screwed up). str still shows the correct value after ReleaseBuffer in GetItemText and is good when you are at the final brace. The next thing you know, you're in OnCustomDraw and the string is gone. Apparently ReleaseBuffer decrements the reference count to 0 and the string goes away when the stack unrolls. Thinking that Blazczak's pooling didn't anticipate CustomDraw calling GetItemText(), ultimately leading to one ReleaseBuffer() call he hadn't anticipated, I tried setting: const unsigned short StringPoolSize = 4; in the PosDialog's .h file and modifying the circular indexing in AddPool to use StringPoolSize (instead of 3), so it now reads: if ( ++nextFreeSlot > StringPoolSize-1 ) nextFreeSlot = 0; No change was evident. As soon as you return from GetItemText
Mike Landis wrote: There are real MFC objects behind the GetDlgItem call, so I think the CWnd*s are real. I use the (cast)ptrs to call CCtrlList, CEdit, etc. functions. I'm not wrapping anything, just subclassing, so I hope I haven't killed NM_CUSTOMDRAW passthrough If you have associated MFC objects, why do you call GetDlgItem? You should have some CListCtrl-derived objects as dialog members, and you should be able to access them easily. The fact you resorted to GetDlgItem suggests they are not there. This would explain missing NM_CUSTOMDRAWs. On the color, the evc3 help doesn't show you the structure under the m_hAttribDC. In the debugger, I can see inside dc to the m_hAttribDC, but only see 'unused' within. Not sure what to do with that. I'm not referring to CDC. To set the color of list item text, you don't call CDC::SetItemText. You just set the clrText member of NMLVCUSTOMDRAW to RGB you need. Pool - is there real reason for pooling? Or you just have a feeling this would be good from perf viewpoint? Tomasz Sowinski -- http://www.shooltz.com
*** Purgamentum init, exit purgamentum ***
-
Mike Landis wrote: There are real MFC objects behind the GetDlgItem call, so I think the CWnd*s are real. I use the (cast)ptrs to call CCtrlList, CEdit, etc. functions. I'm not wrapping anything, just subclassing, so I hope I haven't killed NM_CUSTOMDRAW passthrough If you have associated MFC objects, why do you call GetDlgItem? You should have some CListCtrl-derived objects as dialog members, and you should be able to access them easily. The fact you resorted to GetDlgItem suggests they are not there. This would explain missing NM_CUSTOMDRAWs. On the color, the evc3 help doesn't show you the structure under the m_hAttribDC. In the debugger, I can see inside dc to the m_hAttribDC, but only see 'unused' within. Not sure what to do with that. I'm not referring to CDC. To set the color of list item text, you don't call CDC::SetItemText. You just set the clrText member of NMLVCUSTOMDRAW to RGB you need. Pool - is there real reason for pooling? Or you just have a feeling this would be good from perf viewpoint? Tomasz Sowinski -- http://www.shooltz.com
*** Purgamentum init, exit purgamentum ***
pCustomDraw->clrText = RGB(255,0,0); works like a charm. Saw it in the structure and forgot about it until you reminded me. I am not sure what you're referring to regarding the controls. I build up dialogs by adding controls in the resource editor. I've been finding them by calling GetDlgItem(). It's been working for responding to other messages. I didn't think NM_CUSTOMDRAW worked differently. On Pooling - all I know is that there is a data longevity requirement which Blazczak's AddPool solves. If you don't do it absolutely nothing displays in the list control. This is behaving exactly the same way that it did before I put the pooling in. Blazczak says that you have to cache strings through two LBN_GETDISPINFO notifications after the one where you set the value. - Mike Landis
-
pCustomDraw->clrText = RGB(255,0,0); works like a charm. Saw it in the structure and forgot about it until you reminded me. I am not sure what you're referring to regarding the controls. I build up dialogs by adding controls in the resource editor. I've been finding them by calling GetDlgItem(). It's been working for responding to other messages. I didn't think NM_CUSTOMDRAW worked differently. On Pooling - all I know is that there is a data longevity requirement which Blazczak's AddPool solves. If you don't do it absolutely nothing displays in the list control. This is behaving exactly the same way that it did before I put the pooling in. Blazczak says that you have to cache strings through two LBN_GETDISPINFO notifications after the one where you set the value. - Mike Landis
Mike Landis wrote: I am not sure what you're referring to regarding the controls. I build up dialogs by adding controls in the resource editor. I've been finding them by calling GetDlgItem(). It's been working for responding to other messages. I didn't think NM_CUSTOMDRAW worked differently. Well, when your dialog is created, the controls are Win32 controls. More specifically, list control can be accessed as CListCtrl, but it's not CYourListCtrl unless you subclass it. This is usually by adding data member in ClassWizard (of course you can manually add CYourListCtrl as data member and insert DDX_Control call in DoDataExchange -- or use SubclassDlgItem in OnInitDialog). Mike Landis wrote: On Pooling - all I know is that there is a data longevity requirement which Blazczak's AddPool solves Ok, I see what you mean. This is indeed fragile approach which can fail when you call GetItemText in custom draw handler. I vaguely remember copying text (using strncpy) straight into item.pszText in some list control. But this was on Win32, not CE. You may try that approach - pszText may point to internal buffer when you're receiving LVN_GETDISPINFO. Tomasz Sowinski -- http://www.shooltz.com
*** Purgamentum init, exit purgamentum ***
-
Mike Landis wrote: I am not sure what you're referring to regarding the controls. I build up dialogs by adding controls in the resource editor. I've been finding them by calling GetDlgItem(). It's been working for responding to other messages. I didn't think NM_CUSTOMDRAW worked differently. Well, when your dialog is created, the controls are Win32 controls. More specifically, list control can be accessed as CListCtrl, but it's not CYourListCtrl unless you subclass it. This is usually by adding data member in ClassWizard (of course you can manually add CYourListCtrl as data member and insert DDX_Control call in DoDataExchange -- or use SubclassDlgItem in OnInitDialog). Mike Landis wrote: On Pooling - all I know is that there is a data longevity requirement which Blazczak's AddPool solves Ok, I see what you mean. This is indeed fragile approach which can fail when you call GetItemText in custom draw handler. I vaguely remember copying text (using strncpy) straight into item.pszText in some list control. But this was on Win32, not CE. You may try that approach - pszText may point to internal buffer when you're receiving LVN_GETDISPINFO. Tomasz Sowinski -- http://www.shooltz.com
*** Purgamentum init, exit purgamentum ***
On subclassing, I've been using the Wizard to define classes. Finish the dialog in the resource, Ctrl-W, New class, etc. I think it's sewn together right. If you bring up the Wizard over any of my dialogs, you immediately see the subclass, messages, member functions... Can you post example code or suggest a URL where strncpy is used to solve the longevity problem? I tried boosting the pool size to 12, just to see if it made any difference. It didn't. I am fairly convinced that defeating buffer release will solve this. The application is stable elsewhere. If you find something that gets me valid CString's from GetItemText in the CustomDraw routine, I owe you $100. - Mike Landis
-
On subclassing, I've been using the Wizard to define classes. Finish the dialog in the resource, Ctrl-W, New class, etc. I think it's sewn together right. If you bring up the Wizard over any of my dialogs, you immediately see the subclass, messages, member functions... Can you post example code or suggest a URL where strncpy is used to solve the longevity problem? I tried boosting the pool size to 12, just to see if it made any difference. It didn't. I am fairly convinced that defeating buffer release will solve this. The application is stable elsewhere. If you find something that gets me valid CString's from GetItemText in the CustomDraw routine, I owe you $100. - Mike Landis
Mike Landis wrote: Can you post example code or suggest a URL where strncpy is used to solve the longevity problem? I tried boosting the pool size to 12, just to see if it made any difference. It didn't. I am fairly convinced that defeating buffer release will solve this. The application is stable elsewhere. It's quite late in my timezone, so I'll do that in circa 10 hours. I'm still not sure if this will work, but I'll give it a try. If you find something that gets me valid CString's from GetItemText in the CustomDraw routine, I owe you $100. Can't accept that - help is 100% free at CodeProject :) Tomasz Sowinski -- http://www.shooltz.com
Alika masiaka!
-
On subclassing, I've been using the Wizard to define classes. Finish the dialog in the resource, Ctrl-W, New class, etc. I think it's sewn together right. If you bring up the Wizard over any of my dialogs, you immediately see the subclass, messages, member functions... Can you post example code or suggest a URL where strncpy is used to solve the longevity problem? I tried boosting the pool size to 12, just to see if it made any difference. It didn't. I am fairly convinced that defeating buffer release will solve this. The application is stable elsewhere. If you find something that gets me valid CString's from GetItemText in the CustomDraw routine, I owe you $100. - Mike Landis
Mike Landis wrote: On subclassing, I've been using the Wizard to define classes. Finish the dialog in the resource, Ctrl-W, New class, etc. I think it's sewn together right. If you bring up the Wizard over any of my dialogs, you immediately see the subclass, messages, member functions... Yes, but this only takes care of subclassing the *dialog*. If you want to handle reflected notifications in list control, you'll also have to subclass it. Otherewise, nobody will scan its message map - it'll be plain Win32 control with no MFC window procedure behind. I guess haven't used ClassWizard's 'Member Vars' tab to associate CYourListCtrl with any control ID. How does DoDataExchange looks like in your dialog? It should have something like DDX_Control(pDX, IDC_LIST1, m_lst1); Can you post example code or suggest a URL where strncpy is used to solve the longevity problem? strncpy, or rather wcsncpy - because WinCE is Unicode only - skips over longevity. In your approach, you're trying to keep string data for some time, and you're just setting item.pszText to point inside your pool. But when your LVN_GETDISPINFO handler is called, list control itself has initialized pszText. It points to its internal buffer, managed by Windows. You can create the string you need on the fly, and instead of stuffing it into pool copy it into this buffer using wcsncpy. Here how it looks in my test app running just fine on hp1910:
void CTestListCtrl::OnGetdispinfo(NMHDR* pNMHDR, LRESULT* pResult) { LV_DISPINFO* pdi = (LV_DISPINFO*)pNMHDR; if (LVIF_TEXT & pdi->item.mask) { CString strItem; strItem.Format(_T("Item %d - %d"), pdi->item.iItem, pdi->item.iSubItem); wcsncpy(pdi->item.pszText, strItem, pdi->item.cchTextMax); } *pResult = 0; }You don't care about the lifetime of strItem, because it is copied before leaving OnGetdispinfo. I'm sending the source of my test app to your email account. It's 12 kb zip file; solves all problems you've reported (handles NM_CUSTOMDRAW/LVN_GETDISPINFO in list control class and changes colors of list items). Tomasz Sowinski -- http://www.shooltz.comAlika masiaka!