Maybe you have this file, can you show path?

Thanks so much, I think this is exactly what I want. Lisoft

Thanks a lot, it works! :) Lisoft

lisoft wrote: TTN_NEEDTEXT sent from the control. Have you set the control to send the notify message? Notify = TRUE in the resource editor? Artificial intelligence is no match for natural stupidity. Never argue with an idiot. They will drag you down to their level where they are an expert.

\\......... ON_NOTIFY_REFLECT(LVN_COLUMNCLICK, OnColumnClick) \\......... void CSortListCtrl::OnColumnClick( NMHDR* pNMHDR, LRESULT* pResult ) { NM_LISTVIEW* pNMListView = (NM_LISTVIEW*)pNMHDR; const int iColumn = pNMListView->iSubItem; *pResult = 0; }

I also found the OLE DB consumer templates does not have the EOF/BOF status like the ODBC(MFC) class which I used to access the database before. When CRowset class was first initialized by CCommand::Open method, the 'cursor' does not point to the first record like the ODBC(MFC) class. The only way to check if there is anything returned from the database is to call CRowset::MoveNext() method and check the return value to determine EOF status. Anyway, thanks for your help. Lisoft

This is not necessarily True. MOST of the Win32 API calls involving strings that are used by an ANSI program have to first pass through interal code to CONVERT those strings to Unicode before calling the native UNICODE functions in the WIN32 API and then back into ANSI upon returning any strings. Microsoft has consistently stated that a UNICODE application with a lot of string processing towards WIN32 API function calls would be faster if it were built to use UNICODE. So the question makes sense, why is it slower in UNICODE? I don't really know why.

Maybe if you posted the actual error message someone could help... Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg

Thank you very much! It works. Lisoft

I do use the StretchBlt to copy bitmap from memory dc to the actual dc I got from CPrintDlg::CreateDC(), I think may be the problem is the image I want to print is colored, and the device is just only a black-white printer.

I think StretchBlt api will help ----------------------------- "I Think this Will Help" ----------------------------- Alok Gupta visit me at http://www.thisisalok.tk

That does indeed sound strange. Are you linking with the multithreaded runtime libraries? Because that kind of odd behavior could arise from linking with the single threaded ones.

You do: Somewhere define an event that both threads know about: HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); which is a manual reset event with unsignalled state to begin with. Then in your worker thread: // Do something, stuff, thing or whatever... // Ok Ready, signal the event ::SetEvent(hEvent); Then in thread 2 you just wait for the event // Wait for event to be signalled ::WaitForSingleObject(hEvent, INFINITE); Execution will continue after the ::WaitForSinglObject as soon as the event gets signalled.

Well I'm pretty sure that's what happens when you press the big orange 'X' button. Try this and you'll see what it does. In any of the drop down menus you have create an option called "Quit" and in the code just put PostMessage(WM_QUIT, 0, 0); That will quit the entire app.