3. delay-load the gdi+ DLL and only call gdi+ functions when on xp http://www.catch22.net

You can get the DirectShow wizard to generate the boilerplate code for a push source filter and start from there. http://tmhare.mvps.org/downloads.htm[^] There is also a Bouncing Ball source filter sample in the SDK. Aside from that you would probably need to ask a more specific question.

That CLSID has resolved to 'My Computer' since Windows 95. I see no reason for it to change in the future. "Take only what you need and leave the land as you found it." - Native American Proverb

That's cool, but to be safe, you should always check if FindWindow(Ex) succeeds before using the HWND.

sorry, i tried, you'll have to take it from here.

That sounds weird. I know I get the message in my apps, and I don't do anything special. -- Pictures[^] from my Japan trip.

You can call the ssynchronous WriteFileEx multiple times while IO is pending. What the documentation is trying to conveysay is that the completion CALLBACK will be activated not the event handle. So you need to decode which IO request(s) completed when our IO completion procedure is called with the information you originally provided as part of the IO completion callback setup prior to making the WriteFileEx call.

Thanks all,

Because I wanted to find the focused item, not selected item. By using GetNextItem(), I can directly locate the focused item and that's what I needed. BRs

Thanks Anders, It worked!! BRs.

Thanks for your response, Of course, I did try WS_CLIPCHILDREN and it didn't help. I found an article here talking about this problem. Unfortunately, it works in XP and .Net only. That key is the extended style LVS_EX_DOUBLEBUFFER. No solution for other versions (2K, 98...) And I'm still working and waiting. Thanks again.

Thanks for your response, When WS_CLIPCHILDREN is used, children windows have to do their painting themselves. Unfortunately, static controls, group box controls cannot draw their background. My temporary solution is setting the WS_EX_TRANSPARENT to these kinds of control (e.g. group box). Of course, they will flick, but the others can enjoy flicker-free. So, as what I said, I still used WS_CLIPCHILDREN to prevent flicker except static, group box controls. I'm still waiting for a complete solution. Thanks again.

Look up BeginDeferWindowPos DeferWindowPos EndDeferWindowPos and try using those functions instead. Iain.

Tuan Dang wrote: I think the approach to key HKEY_LOCAL_MACHINE\SYSTEM\DISK\Information is correct. Except that that key does not always exist. The two machines on my desk do not have that key. "Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow

Some lines of simple code: //////////////////////////////////////////////////////////////// MENUITEMINFO mmi, temp; ZeroMemory(&mmi,sizeof(mmi)); mmi.cbSize = sizeof(mmi); // Assign user data to menu item mmi.fMask = MIIM_DATA; mmi.dwItemData = (DWORD) pData; ::SetMenuItemInfo(pMenu->m_hMenu, nPos, TRUE, &mmi); // Try getting the data back for testing purpose temp.cbSize = sizeof(MENUITEMINFO); temp.fMask = MIIM_DATA; BOOL rc = ::GetMenuItemInfo(pMenu->m_hMenu, nPos, TRUE, &temp); if (!rc) { int iErrCode = GetLastError(); // iErrCode will be 87 } When waiting for your replies, I found that the function GetMenuItemInfo will work properly in WinNT if (cbSize==sizeof(MENUITEMINFO) - 4). I think the problem is somewhere around the WINVER. In WinUser.h I saw these: typedef struct tagMENUITEMINFOW { UINT cbSize; UINT fMask; UINT fType; // used if MIIM_TYPE (4.0) or MIIM_FTYPE (>4.0) UINT fState; // used if MIIM_STATE UINT wID; // used if MIIM_ID HMENU hSubMenu; // used if MIIM_SUBMENU HBITMAP hbmpChecked; // used if MIIM_CHECKMARKS HBITMAP hbmpUnchecked; // used if MIIM_CHECKMARKS ULONG_PTR dwItemData; // used if MIIM_DATA LPWSTR dwTypeData; // used if MIIM_TYPE (4.0) or MIIM_STRING (>4.0) UINT cch; // used if MIIM_TYPE (4.0) or MIIM_STRING (>4.0) #if(WINVER >= 0x0500) HBITMAP hbmpItem; // used if MIIM_BITMAP #endif } So, I think the function GetMenuItemInfo failed in Windows NT because of the size of returned variable LPMENUITEMINFO(&temp). GetMenuItemInfo expected to see the size of returned variable is 44. However, sizeof(MENUITEMINFO) returned 48. In my opinion, this caused the error. Anyway, thanks for your replies. ____ Tuan