When using WTL 7.0 with ActiveX controls under ATL 7.1, the framework will ASSERT inside atlcom.h on the following line:
ATLASSERT(!InlineIsEqualGUID(*m_plibid,GUID_NULL) && "Did you forget to pass the LIBID to CComModule::Init?");
This can be solved one of two ways:
1) Change your "Use of ATL" setting to "Dynamic Link to ATL" in your project properties.
2) Change your "Use of ATL" setting to "Static Link to ATL" and instead of using
hRes = _Module.Init(NULL, hInstance);
line in your _tWinMain, use this instead:
GUID guid;
hRes = _Module.Init(NULL, hInstance, &guid);
The ATLASSERT is apparently a bug in ATL 7.0/7.1 because everything works right if you pass a non-null GUID to _Module.Init(). Note that some people prefer to pass the actual LIBID instead of a garbage GUID, but this has no effect on whether the framework works correctly or not.
I was unsure whether to post this under GDI or WTL, but WTL won out since I was using CScrollImpl when I encountered this problem. On one of the views in my WTL program, I was creating controls dynamically on the output screen. This worked fine until the controls I was creating extended beyond the range of the viewport. When I kept using the same RECT coordinates for the created controls in the scrolled view, I started having all sorts of positioning and resizing problems.
Turns out that Create assumes that the RECT coordinates you specify in the call are from the top of the viewport, not the top of the window. This was not at all intuitive to me. Consequently, if you want to keep a common coordinate system when creating controls on a scrolling view, you must either 1) factor in the scroll bar offset yourself, or 2) scroll back to the top left of the window (without updating), place your controls and then scroll back to the proper position.
By default, the COM Server code that the WTL AppWizard adds does not have the _Module.RegisterServer function set to TRUE by default. As a result, the type library information never showed up in the registry. A message in the ATL Archives relayed the answer to this problem.
After trying to use extended combo boxes within a WTL app and not getting them to load, I knew I must be doing something wrong. I was initializing them with ::InitCommonControlsEx() in OnInitDialog(), which was a little too late. I moved them to DllMain, and that solved the problem. (The Microsoft ATL mailing list archives saved the day ...)
I was trying to modify a WTL frame window by using ModifyStyle in OnCreate(). WTL doesn't like this very well. Instead I discovered that I got the results I was looking for by modifying CFrameWindowImpl to take a customized version of CWinTraits by adding it to the template definition. By the way, this also works for CWindowImpl, which is where I found this trick in the MSDN docs and ATL Internals. Also, this link shows another tricky portion of the whole process.
Steps to use CDialogResize (from WTL 3.1):
1) #include <atlframe.h> in your view/dialog class
2) derive your view/dialog from CDialogResize:
class CMyClass: public CDialogImpl<CMyClass>, ....
public CDialogResize<CMyClass>
3) Add a DLGRESIZE_MAP to your view as follows:
BEGIN_DLGRESIZE_MAP(CMyClass)
DLGRESIZE_CONTROL(IDOK, DLSZ_MOVE_X | DLSZ_SIZE_Y)
END_DLGRESIZE_MAP()
The first parameter in the DLGRESIZE_CONTROL macro is the resource ID of your control. The second parameter(s) is the way that you want that control to be resized; valid values are DLSZ_MOVE_X, DLSZ_MOVE_Y, DLSZ_SIZE_X, DLSZ_SIZE_Y. (Note that you can OR these together with a |). You can also resize controls as a group by enclosing a number of DLGRESIZE_CONTROL macros with BEGIN_DLGRESIZE_GROUP() and END_DLGRESIZE_GROUP(). More on grouping in the next tip.
4) Chain your message map to CDialogResize, i.e.
BEGIN_MSG_MAP(CMyClass)
....
CHAIN_MSG_MAP(CDialogResize<CMyClass>)
END_MSG_MAP()
5) Initialize the resizing for your view with DlgResize_Init(false, true, WS_CLIPCHILDREN) in OnInitDialog. Normally (for standard dialogs) you would just use DlgResize_Init() and accept the default parameters, but for a view you have to supply the extra settings since the view doesn't need a gripper or a frame like a dialog would.
Some things I've noticed about grouping controls with CDialogResize:
1) You can group controls in one direction and leave them ungrouped in another direction to achieve good effects.
For instance, if you had Save, Print and Close buttons running along the bottom of your dialog, centered and spaced evenly apart, you'd probably want to do this grouping:
BEGIN_DLGRESIZE_MAP(CMyClass)
BEGIN_DLGRESIZE_GROUP()
DLGRESIZE_CONTROL(IDC_BTN_SAVE, DLSZ_MOVE_X )
DLGRESIZE_CONTROL(IDC_BTN_PRINT, DLSZ_MOVE_X )
DLGRESIZE_CONTROL(IDC_BTN_CLOSE, DLSZ_MOVE_X)
END_DLGRESIZE_GROUP()
DLGRESIZE_CONTROL(IDC_BTN_SAVE, DLSZ_MOVE_Y)
DLGRESIZE_CONTROL(IDC_BTN_PRINT, DLSZ_MOVE_Y)
DLGRESIZE_CONTROL(IDC_BTN_CLOSE, DLSZ_MOVE_Y)
END_DLGRESIZE_MAP()
This would keep all of them centered and spaced evenly as you moved them, while also moving them up and down independently.
2) As soon as you noticed this little trick, however, you might start to take notice that your buttons don't exactly line up with the other controls on screen. You'd see this as the dialog was sized larger and larger. What's happening is that the leftmost button in the resource (this doesn't mean the top one in the DLGRESIZE_GROUP -- it's unrelated) is acting as an anchor for all the other buttons in the group. So when you resize the dialog, the leftmost button isn't moving ... it's just staying in place.
There may be better ways to solve this problem, but what I did is insert a new invisible button on the resource in the leftmost position to act as the anchor. I then included the button in the DLGRESIZE_GROUP with a DLSZ_MOVE_X command as well so it would make all the other three buttons move together correctly. Like I said -- it works. If you stumble on something better