Thank you for your feedback. The range macros of which I was aware were: ON_COMMAND_RANGE, and ON_CONTROL_RANGE, neither of which matched the function prototype I normally use for a spin button control. The ON_NOTIFY_RANGE worked great. However, I did have to add an ID parameter to the message handling function. [The first parameter, in case anyone is interested.] Due to the additional parameter, one need not use the mentioned structure members to identify the control.

Use a list-view[^] (aka CListCtrl[^]) and process its NM_CLICK[^] or LVN_ITEMCHANGING[^] notifications? The second one will be fired when an item is going to be selected, so you could cancel that and change its state? You cancel the change by returning TRUE from the nmotification handler, I believe, although that page doesn't say so - the Windows Mobile equivalent page[^] does say so! Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

there is a cover (window) in front of main frame window, mouse movement is delivered to taht front window.

It's been a while since I used that, but I found some code for an owner-drawn CClassListBox (derived from CListBox) without "has strings", in which: I added items to the listbox using something like int CClassListBox::AddItem(CFormClass* pClass) { ASSERT_VALID(pClass); return AddString((char*) pClass); } int CClassListBox::InsertItem(UINT nIndex, CFormClass* pClass) { ASSERT_VALID(pClass); return InsertString(nIndex, (char*) pClass); } then DrawItem, MeasureItem, CompareItem, etc., received these CFormClass pointers as the itemData fields. The CompareItem() implementation was: int CClassListBox::CompareItem(LPCOMPAREITEMSTRUCT lpCIS) { CFormClass* pI1 = (CFormClass*) lpCIS->itemData1; CFormClass* pI2 = (CFormClass*) lpCIS->itemData2; ASSERT\_VALID(pI1); ASSERT\_VALID(pI2); ASSERT(pI1->IsKindOf(RUNTIME\_CLASS(CFormClass))); ASSERT(pI2->IsKindOf(RUNTIME\_CLASS(CFormClass))); if (pI1->IsGraphic() && !pI2->IsGraphic()) return -1; if (!pI1->IsGraphic() && pI2->IsGraphic()) return 1; int i = stricmp(pI1->GetName(),pI2->GetName()); if (i < 0) i = -1; else if (i > 0) i = 1; return i; } Hope that helps, -- jlr http://jlamas.blogspot.com/[^]

I will check into it. Thank you very much.

I was able to accomplish my goal by handling WM_MENUSELECT; Thanks

Thanks for the info! I have found that NTFS does not support extended attributes in the sense that OS/2 does (unfortunately, in my opinion). However, it does support multiple data streams. Normally, the default (unnamed) data stream is accessed. I can use a named data stream to achieve my purpose, though I have to jump through a few hoops. Thanks for the feedback!

Thanks for the information and your offer to zip and send me the code. I will look into the Q article, as well as another possibility. If I think the zipped code would be useful, I'll send you an email. Thanks again for the offer.

CWnd::GetDesktopWindow()->GetWindowRect (...); Although this will return the same screen size regardless of the presence of app bars. You probably want the size of the workspace. /ravi My new year's resolution: 2048 x 1536 Home | Articles | Freeware | Music ravib@ravib.com

That is some good thinking. I should have posted that I "solved" this problem. First of all, it turned out that tooltips did appear every once in a while, maybe once out of 50 times that the cursor was moved over the button. In an effort to solve the problem, I started getting earlier versions of my source code out of Source Safe, and each time, the tool tips worked. Finally, I got to where there was a trivial difference between the "current" source and the source that did not work, a difference that could not matter, it seemed to me. Let me mention here that I did "rebuild all"s on the "current" version, which did not help. Finally, I checked out the current version of the code to a fresh directory. In other words, I checked out code identical to the source code which exhibited the problem. When I built the project, tool tips worked! I will say that I do not check in .dsw, .clw, or any of the "project" files, other than .dsp (well, .rc and resource.h are checked in, of course). I simply do not know. It seems so odd to me. I never did try deleting all the files from the "debug" or "release" folders, rather than just doing a rebuild all. Perhaps it was evil electrons.

I was able to make a CMenu work, thank you. The issue was that the entries to be placed in the menu were dynamically determined at run time. Having a method for each possible message didn't seem clean, and would have limited me to a maximum number of entries in the menu. cmk suggested that I use a method which handled a command range. Being an MFC neophyte, I was unaware of this possibility (and specifically that the command id was a parm to the method). This solved the problem. Thanks.

Thank you very much, that was very useful, and solved the problem nicely. I was about to search the MFC header files for "ON_COMMAND" to see if I could find something nearby that seemed suitable for a range (as you had suggested earlier), when I received your message. Once I saw the ON_COMMAND_RANGE and that the associated method received the command id as a parameter, the solution was clear. Thanks again. P.S. Sorry for taking so long to respond, I've been a bit under the weather.

The problem is that I don't want a "Select Widget" selection to appear as a choice when the combo box drops down. Thanks for your input.