WTL::CImageList and ::GetIconInfo() got the best of me today. It turned out WTL::CImageList::~CImageList() doesn't free the encapsulated HIMAGELIST, and that ::GetIconInfo() allocate bitmaps which the caller has to free.
On top of that, I tried using a trial version of boundschecker to find the problem quick and easy. Guess what? Boundschecker is a lying and incompetent piece of sh*t software. It reported a bunch of false positives (verified by seeing the debugger stop at break points in destructors of "unfreed" objects), it can't ref count on COM objects (I saw the IPicture->Release() return 0!), it also never figured out that my image lists were leaking. Tough day at the office.
But I have noticed an odd thing with GDI objects in general. Something which all programs exhibit, and sometimes even more so when themes are turned on. When you open a dialog (any dialog - you can try with the about box for IE to see for yourself), the GDI object count goes up, let's say X + n. Understandable. But when I close the dialog, the count doesn't go down as much as it went up, let's say X + n - m, where m < n. However, if I reopen the dialog, the GDI object count goes up to X + n again, and back to X + n - m when I close it. It seems as if the dialog resource itself is cached in memory somewhere whenever it's been loaded from the resource part of the exe/dll. I wish I had the source code for CreateDialog(), because now I'm really curious
So, anyway, tomorrow I'll be back on track again to finish off my accelerator stuff.
Hi, every one, I got a problem when using the ::GetModuleHandle API, it always fails if I pass in an absolute path, for example, ::GetModuleHandle("c:\\my app\\app.dll"); will fail even though the file "c:\\my app\\app.dll" exists, but if I copy the program into that directory and call ::GetModuleHandle("app"); it succeeds.
Why can't I use an absolute path for the module? Thank you.
A suspicion I have is that perhaps the module is in several places on your machine.
The one your process is loading is probably not the full path you are testing.
You can try this topic from MSDN: "Enumerating All Modules For a Process" to determine if the module you are loading is actually from the path you suspect. If it is not indeed loaded from that specific path, then the function call will fail.
I'm trying to customize the look of the standard scrollbars.
I have first made them flat with InitializeFlatSB and have modified their size and background color with FlatSB_SetScrollProp and flags WSB_PROP_CYHSCROLL and WSB_PROP_HBKGCOLOR. So far so good.
PROBLEM is that the flag WSB_PROP_PALETTE (requiring a HPALETTE struct as new value) does not affect the appearance of the scrollbars despite the function FlatSB_SetScrollProp success. The test code I use is as follows:
I also had same issue... Someone may pls help..
One more issue I found is, when I change BK color of FlatSB to black, it is displayed as black and white checks... I want it to be fully black.. Any suggestion??
hi this might be a stupid question but im wondering if its possible to have mscv recognize other file extensions as valid source files
for instance im working with .cc files from linux but msvc just treats them like text files and doesnt do any syntax coloring or auto spacing is there a way to make it recognize this file type
i tried to set the files to be opened by mscv but again just treats it like a text file
if szBuffer is something like "Hello world"
then the server recieves the string in two parts
the first being "Hello" and the second being "world"
so i think you get my point, it seems to be breaking the data by spaces and sending each word
it may be appending the space too, (havnt tested)
now i want it to send "Hello world" all at once instead of by each word, i thought about replacing the spaces with something else, but i dont really want to do that
I presume szBuffer is comething like LPTSTR, LPSTR, TCHAR * or char *, in which case, the sizeof operator will return the size of the pointer, not the buffer. You need to pass in the size of the buffer, or use strlen (may be vulnerable to buffer overflows).