If one looks at the MS documentation on PSN_WIZFINISH it is said that with version 5.80 of "comctl32.dll" you can return a window handle to 1) prevent the wizard from finishing and 2) set the focus on the window handle returned by the function. However, WTL negates the result so that returning TRUE allow the wizard to finish while returning FALSE prevent it. By doing so it is not possible to return a window handle.

For modeless wizard property sheet, once you clicked on the "Terminate" button the sheet should be destroyed by calling DestroyWindow. However the WTL instructions that handle that only check for IDOK and IDCANCEL not the identifier of the "Terminate Button"

Some useful links

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

About the Author

Comments and Discussions

The image when loaded to the header of a List control instead of actual transparency, It gives white color replacement for the transprent color.
http://www.codeproject.com/buglist/loadimagebug.asp
I used image (bitmap03.bmp or Bitmap8_02.bmp) from this source and the red background is replaced with white instead of the background color of the list control header. that is the LoadImage function with TRANSPARENT mode on, replaces the back ground color with White instead of the background color of the control the image is placed on.

I'd like to incorporate some of these bug fixes but I don't know how to do it. I'm particularly interested in the fix for InvokeFromFuncInfo in ATLCOM.h.

I thought that since this was an inline function I could just put in the fix, recompile and I'd be done. I tried this but discovered that when I stepped through the code the lines that I added were not accounted for. I rebuilt (so that the pre-compiled stuff would be recompiled) but that didn't work either.

Then I remembered that there is an atl.dll file that my project presumably uses at run time. Apparently, the old code is locked in there. It seems to me the only way to have the fixes to take would be to recompile a new atl.dll and then ship that with my product. Unfortunately, the ATL source code that shipped with VC6 doesn't compile. I'm not sure if it was meant to be compiled; I think it was intended to only be used as a reference.

Am I missing something? How do I get the bug fix for InvokeFromFuncInfo to take? Any guidance would be a huge help.

On line 1980 of atlhttp.inl (ATL 7.1), the call to m_current.Append() should pass the size of the data to append (otherwise if the data is binary and contains nulls, the default behavior of Append is to use strlen, which will cause append prematurely crop the data at the first null).

Existing code:
if (!m_current.Append((LPCSTR)result_buffer))

Should be:
if (!m_current.Append((LPCSTR)result_buffer, result_buffer.GetLength()))

DlgResize_PositionControl() calls MapWindowPoints() and checks the return value against 0, and bails if it is 0. However, 0 does not indicate an error when the window is the same size as the screen, so this fails incorrectly. Change

Make a dialog-based app, add CDialogResize support to it (an empty map and a call to DlgResize_Init() in OnInitDialog()), and the app will crash on exit.
Fix: Remove _ATL_MIN_CRT from the preprocessor defines. (Odd that the app still links with _ATL_MIN_CRT defined.)

The cause is dtors are called after heap manager is gone.
You can change in YOURDLG_app.cpp in _tWinMain
-- from
int nRet = dlgMain.DoModal();
-- to
int nRet;
{
CMainDlg dlgMain;
nRet = dlgMain.DoModal();
}
for a solution which works with _ATL_MIN_CRT

I encountered a bug of the Command Bar. If one menu item of the menu is disabled and you move with the mouse over it, the icons aren't drawn correctly. This does *not* occur on Windows 2000, only on Win98. Anyone knows a solution?

I created a simple multi-threaded SDI application using the WTL-AppWizard. Now I want to display a dialog before the SDI window is displayed (before CTheardManager::Run is called). I did this but now the application process is never terminated even if all SDI windows are closed. Did anyone encounter the same problem and knows a solution?

I created a simple multi-threaded SDI application using the WTL-AppWizard. Now I want to display a dialog before the SDI window is displayed (before CTheardManager::Run is called).
I did this but now the application process is never terminated even if all SDI windows are closed.

Are you sure ? MFC::CString::~CString is coded in the same way.
And nobody met this bug. Probably something is wrong with your code.
You should check up how you create threads, and how you create and destroy strings.
The memory manager used for freeing the string memory should match with that that was used for creation.

And yes, I know about the so called support page on Micorosoft, but I want proof that it works before I use it! (I've reported bugs ages ago in the OLE DB templates that I haven't even seen in the bug list yet!)

If you are interested in the bug I found in WTL::CString, it's everywhere. I have an annoying habit of compiling in Unicode, mostly since I only work on NT for my small projects. This has broken code before, especially code from books etc.

In CString::TrimRight for example, the new length of the string is computed like this:

Somebody has tried to make it Win64 safe, but broken Unicode in the process. The reason is of course that the compiler knows that lpszLast and m_pchData are LPCTSTR which are 1 byte normally but 2 byte in Unicode. But the cast treats them as numbers, which means that the string length will be twice shorter than the spaces found! Bloody annoying!

If you look at the MFC counterpart, it looks like this:

GetData()->nDataLength = (int)(lpszLast - m_pchData);

Which works. I've inserted it into my atlmisc.h at it seems to be working.

The implementation of _IsDBCSTrailByte is guite different from the implementation of _ismbstrail(CRT).
I think it can't be determined whether a character is a trailing byte or not
without the way _ismbstrail uses...

Basically, the algorithm looks backwards from lpstr[nChar] and looks for values that can't be lead bytes. At the end of the loop, i holds the index of the last possible lead byte found. lpstr[nChar] is then a trail byte only if nChar-i is odd, meaning nChar is 1, 3, 5, etc., bytes away from the last possible lead byte.

It actually makes sense, although some comments in the code would've been nice!

When I make a menu popup by access key(Alt+x),
although the menu is still popup,
WM_MENUSELECT which means the menu closing seems to be sent to the mainframe window.

This makes a fatal problem when I am changing the menu items dynamically.
If I believe this false WM_MENUSELECT and clean up my dynamic menu items,
a strange menu will be popup and sometimes makes my application hung up.

Is this bug?
This false WM_MENUSELECT is never sent when I don't use command bar.

Thank you.

And about another command bar problem see also:
http://www.codeproject.com/useritems/donut.asp?forumid=1333&select=14062&tid=14062#xx14062xx

Methods AddBitmap or AddButton of CToolBarCtrl class in some cases may fail cause...
If the toolbar was created using the CreateWindowEx function, you must send the TB_BUTTONSTRUCTSIZE message to the toolbar before sending TB_ADDBITMAP or TB_ADDBUTTONS.

I was just wondering about the proposed fix for the
IsEqualObject. I think this would violate the identity
rules for COM. Following abstract from MSDN;

For any one object, a specific query for the IUnknown interface on any of the object's interfaces must always return the same pointer value. This allows a client to determine whether two pointers point to the same component by calling QueryInterface on both and comparing the results. It is specifically not the case that queries for interfaces (even the same interface through the same pointer) must return the same pointer value.

So unless the the interface pointers are explicitly
queried for as IUnknown, the proposed performance enhancement might result in an invalid comparision.

I think it is safe to say that if two pointers are the same, then it is the same object. What the abstract is trying to say is that if the two pointers are different, then it doesn't hold true that they must be different objects. Thus the query for IUnknown.

NB: you'll notice that if you use command bars then the width of the vertical command bar won't be perfect for the text of the menu. Maybe someone else can solve that bug. I currently don't use command bars so I don't have any urgency.