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.com

Alika masiaka!

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!

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: 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: 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!

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!

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!

Probably the window class for custom control is not registered before DoModal call. Are you trying to call RegisterClass in OnInitDialog? Tomasz Sowinski -- http://www.shooltz.com

Alika masiaka!

Actually, you should use CClientDC instead of manual GetDC/ReleaseDC calls. It will call these functions for you in its constructor and destructor. Similarly, you can use CPaintDC in WM_PAINT-handling code. Tomasz Sowinski -- http://www.shooltz.com

Alika masiaka!

dolph_loe wrote: My question is: How do I clean up the document template objects on exit? Shouldn't CWinApp do that? You don't. CYourApp will delete the doc template object in its destructor. Can you set the breakpoint in your app destructor and step into CWinApp::~CWinApp from there? Tomasz Sowinski -- http://www.shooltz.com

Alika masiaka!

/Y3 should do the trick Tomasz Sowinski -- http://www.shooltz.com

Alika masiaka!

ceuba wrote: When i alredy had terminated the programm b.exe and it doesn't exist in the tast-manager. I do step 2 and the handle is alawy not NULL. But i see this effect only in XP. W2k show me NULL and I can start b.exe with createprocess. The process ID may be reused, so maybe you're getting the handle for other process? Anyway, since you're calling CreateProcess yourself, why don't you use another thread and WaitForSingleObject? Tomasz Sowinski -- http://www.shooltz.com

The classic article on view swapping is here: http://www.microsoft.com/msj/archive/SFFD.aspx[^] Tomasz Sowinski -- http://www.shooltz.com

From the top of my head: maybe instead of PROCESS_ALL_ACCESS you should use PROCESS_TERMINATE? Tomasz Sowinski -- http://www.shooltz.com

I guess it's CMenu::TrackPopupMenu you're looking for, probably with TPM_RETURNCMD flag. Tomasz Sowinski -- http://www.shooltz.com

no animal was harmed more than once during creation of this post

You could theoretically get some perf boost from Whole Program Optimization introduced in 7.0. Of course, it greatly depends on specifics of your code. Did you actually profile it, anyway? :) Tomasz Sowinski -- http://www.shooltz.com

Thanks, Nemanja. I was just passing by and had a look at good ol' VC board :) Tomasz Sowinski -- http://www.shooltz.com

Check this: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3[^] Tomasz Sowinski -- http://www.shooltz.com

signature has expired

Difficulty Level: Easy Time Required: 5 minutes How to Make and Drink a Blow Job.[^] Tomasz Sowinski -- http://www.shooltz.com

*** Purgamentum init, exit purgamentum ***