It seems more information is needed in order to answer this, since there is no specific question. You want to know why your code doesn't work but you haven't given us all the information required to answer it. Perhaps showing the code that is relevant will help us catch something.

This fascinates most programmers. Your size depends a lot on the compile settings you have. Are you statically linking into ATL? Is it a debug version? Do you have it optimized for speed or size? Are you using exception handling? All these things take up space, personally I think you've linked into the C runtime library statically, so you have /MD Multi-threaded. If you select /MD you'll link dynamically and won't have to have a copy of strcpy and what not in your application. Some people have been known to make their application really small by not using the C runtime and writing or calling the Windows equivalent of all the C runtime functions. Hope this helps, Mark

If you are looking for something to log all queries from a database check the documentation. Most, if not all, database implementations support a way trace all the SQL commands made to their database. That would be a lot easier then injecting your code and logging them yourself. Even if you can't restrict it to one table, you can log everything and later use something like grep to get just the lines you are interested in. Hope this helps. /Mark

First you have to get the DLL over to that machine. So it's a simple case of how do you want to get the file over there. You have options: E-mail, on a floppy, windows file sharing, etc.

Hi Leela, Take a look at code injection, there are some really good articles on codeproject about it. http://www.codeproject.com/threads/winspy.asp http://www.codeproject.com/system/inject2exe.asp http://www.codeproject.com/useritems/inject2it.asp /Mark

SetItemText is just a wrapper for LVM_SETITEMTEXT, which will be sent using SendMessageA because _UNICODE is not set. Be aware however that even if you send "unicode" messages to a window, windows will automatically convert them to ansi if the window is not unicode window. There are no samples that I know of, the easiest thing would be just to make the entire application unicode.

This is tricky but you can actually mix unicode and ansi windows within an Application. When you define _UNICODE all the macros get mapped their *W functions. So SendMessage becomes SendMessageW, etc. Windows converts between unicode and ansi between windows your behalf so that if you call SetWindowText from an ansi program to a unicode program, the recieving program will get unicode from the ansi that the sender sent. Windows tells if a window is unicode or not by how it was created. So RegisterClassA would be an window procedure expecting ansi and RegisterClassW excepts unicode. You can change this by calling SetWindowLongPtrW and passing GCLP_WNDPROC with a new WndProc. Make sure to end your new WndProc with CallWindowProcA because the original accepts ansi. This will however make the entire control unicode. If your really want to save every character you can and only want that column's strings in Unicode you can try a combination of LVS_OWNERDATA and LVS_OWNERDRAWFIXED to manage your own strings and drawing.

You want the WS_EX_APPWINDOW style. You can set this in the dialog properties window with the "Application Window" flag.

That is a classic. Your reading a null pointer. The following program will cause the same error. int* x = 0; *x = 1638; When you get the message, click cancel so that it will load it in the debugger. Use the call stack to see where your reading the null pointer.

catch the HDN_ITEMDBLCLICK notification from the header control embedded in the ListView control.

What about using the bullet character if your font supports it. • Like so. It's alt + 0149 or U+2022. Else you'll have to draw one yourself using GDI.

Since your trying to take complete control over the system, you should act like it. You have to be firm. I'd say set up a system wide hook listening to WM_MOUSEMOVE messages, and just throw them all away. The cursor should no longer move. Look at SetWindowsHookEx(), remember your message pump must reside outside your application in a DLL if it's going to be global.

I believe you want CheckRadioButton() or maybe just CheckDlgButton()

DWORD vol; waveOutGetVolume(0, &vol);

Check out IsHungAppWindow()

Whoever detects the error and then calls SetLastError().

$25USD to $30USD a week feeding just myself (and my girlfriend most evenings). This includes the $7USD to $12USD I spend on jumbo shrimp, shark, or red snapper fillets.

Handle TCN_SELCHANGE instead of WM_LBUTTONDBLCLK

Good question. From the MSDN on LOGFONT: If lfWidth is zero, the aspect ratio of the device is matched against the digitization aspect ratio of the available fonts to find the closest match, determined by the absolute value of the difference. The height of a font is in logical units. Which is why a font at size 8 can look huge on a computer with large fonts set. The Windows GDI was designed to make as little assumptions as possible about what it's drawing on. On a printer 20 pixels is very tiny because it's DPI is so high. There are even monitors that aren't at the normal 96 dpi, so these would not look right if it was embedded with a nonlogical number. Some devices don't even use pixels but other measurements, like twips, so until the DC is set with this information you can't get the width on some fonts. Why can't you get the font's average width logical units? I'm not sure, perhaps it has to do mostly with the font, whether an accurate font to that size has been selected or not, or whether a font author must set this information in the header. Maybe windows is just reluctant to provide such an inaccurate approximation, I don't know. In my opinion it doesn't seem like a big deal (apart from being interesting) since it's a logical value anyways. If you were to use it, you'd have to make all the calculations that GetTextMetrics makes for it to work across all DCs. I can't see where you'd use it without a DC. I hope this makes things somewhat clearer.

You could use CreateProcess() and TerminateProcess(), however TerminateProcess() ends a program so abruptly that some applications don't handle it well, it doesn't give them time to save their settings or other exit code. I'd recommend using FindWindowEx() and sending a WM_CLOSE to the main window.