The Developer's Resource & Community Site |
| COM | XML | ASP | Java & Misc. | NEW: VS.NET |
| International | This Week | Forums | Author Central | Find a Job |
|
WTL Bugs and Issues The following is a list of current issues in WTL. Most of these messages have been copied from the ATL mailing list (https://discuss.microsoft.com/atl) or from personal emails. There have also been some WTL bug reports on the various Microsoft public newsgroups (news://microsoft.public.vc.atl). If you have WTL bugs to report, or fixes, then can you post them on the WTL forum page and we'll get them posted here. From: Dr Richard Grimes <[email protected]> This is an observation with toolbars. If I (rather perversely) drag the menu bar to below the toolbar and then use View | Toolbar to turn off the toolbar, the menu bar is hidden and not the toolbar! Because you haven't got the menu it means that you cannot use it to get it back again! Date: Sun, 26 Mar 2000 21:15:33 -0600 I noticed a small bug in the WTL AppWizard generated code related to the hiding and showing of rebar bands.To recreate it generate an SDI application with all of the defaults, then compile and run.Drag the menubar below the toolbar, then uncheck "View | Toolbar". The menubar should disappear instead of the toolbar.The problem is that OnViewToolBar() naively assumes that the toolbar will always be band #1, but if I put it above the menubar it isn't band #1 anymore.Does anyone know of a quick fix for this? Thanks, Joel Date: Sun, 26 Mar 2000 23:32:07 -0500 You can either fix the band order:
CMainFrame::OnCreate(...)
{
...
CreateSimpleReBar(ATL_SIMPLE_REBAR_NOBORDER_STYLE
| RBS_FIXEDORDER);
...
}
or make sure you're showing/hiding a toolbar:
LRESULT OnViewToolBar(WORD, WORD, HWND , BOOL&)
{
static BOOL bNew = TRUE; // initially visible
CString sBandName;
CReBarCtrl rebar(m_hWndToolBar);
CToolBarCtrl toolbar;
INT nBands = rebar.GetBandCount();
REBARBANDINFO rbbi={0};
rbbi.cbSize = sizeof(rbbi);
rbbi.fMask = RBBIM_CHILD;
for (INT i = 0; i< nBands; i++){
rebar.GetBandInfo(i, &rbbi);
sBandName.Empty();
GetClassName(rbbi.hwndChild,
sBandName.GetBufferSetLength(64), 64);
sBandName.ReleaseBuffer();
if (sBandName == toolbar.GetWndClassName()){
bNew = !bNew;
rebar.ShowBand(i, bNew);
UISetCheck(ID_VIEW_TOOLBAR, bNew);
UpdateLayout();
break;
}
}
return 0;
}
Date: Mon, 27 Mar 2000 00:04:09 -0500 OR - more elegantly - when you CreateSimpleToolBarCtrl(), cache the hWndToolBar. (You might name the member variable 'm_hWndChildTB' or somesuch, since 'm_hWndToolBar' is the rebar.) Then you can avoid all the string rigmarole:
LRESULT OnViewToolBar(WORD, WORD, HWND, BOOL&)
{
static BOOL bNew = TRUE; // initially visible
CReBarCtrl rebar(m_hWndToolBar);
INT nBands = rebar.GetBandCount();
REBARBANDINFO rbbi={0};
rbbi.cbSize = sizeof(rbbi);
rbbi.fMask = RBBIM_CHILD;
for (INT i = 0; i< nBands; i++){
rebar.GetBandInfo(i, &rbbi);
if (rbbi.hwndChild == m_hWndChildTB){
bNew = !bNew;
rebar.ShowBand(i, bNew);
UISetCheck(ID_VIEW_TOOLBAR, bNew);
UpdateLayout();
break;
}
}
return 0;
}
From: "Dr Richard Grimes" <[email protected]> Nenad, Here's an interesting one. I am doing this in an ANSI build:
CString str(L"test");
I find that _wcstombsz() in the LPCWSTR constructor fails to convert because WideCharToMultiByte() fails with an error of 0x57. The problem is because the first parameter is CP_THREAD_ACP. If I do this in a UNICODE build:
CString str("test");
then I get the same problem in _mbstowcsz(). I have tried calling SetThreadLocale() but that does not change anything. My question is should GetACP() be used instead of CP_THREAD_ACP, because on NT4sp6 I cannot get this flag to work. Richard. From: Dr Richard Grimes <[email protected]> Nenad, This first one is not really earth-shattering, but it is a bit odd: The 2nd page of the AppWizard does not enable the command bar check box if the rebar check box is not enabled - that seems like a good idea. However if I uncheck the rebar box and then click on the Back button and then click on Next to get back to the 2nd page, then both the rebar and command bar check boxes are unchecked but enabled - so I can select the command bar box without the rebar. Another thing is that I cannot get the "Host ActiveX Controls" check box to enable. When I base the view on IE there are no scroll bars - the m_view.Create() call in CMainFrame::OnCreate() needs to have the scroll styles. Richard From: Dr Richard Grimes <[email protected]> When I create a dialog based project I get the following maindlg class:
class CMainDlg : public
CDialogImpl<CMainDlg>, CUpdateUI<CMainDlg>,
public CMessageFilter, public CIdleHandler
{/* etc */};
shouldn't the CUpdateUI be a public base class? Richard Date: Thu, 20 Jan 2000 10:03:36 +0100 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:
GetData()->nDataLength = (int)((DWORD_PTR)lpszLast -
(DWORD_PTR)m_pchData);
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. /Andreas Magnusson Date: Wed, 26 Jan 2000 11:27:58 -0600 First off, is this list an appropriate place to discuss WTL?If not please direct me. To replicate this bug(?) create a WTL application and select 'Dialog Based' as the type and check the box 'Create as a COM Server'.The problem is that when you run the application in the debugger (by hitting F5) and then close the dialog (OK,Cancel,etc.) you will get the error "First chance exception in WTLDialog.exe (NTDLL.DLL): 0xC0000008: Invalid Handle".The error is occuring in AtlApp.h in the class CServerAppModule.The code is shown here and it crashes when trying to step into CloseHandle.
void Term()
{
if (m_hEventShutdown != NULL)
CloseHandle(m_hEventShutdown);
CAppModule::Term();
}
I put in breakpoints in the StartMonitor function to make sure m_hEventShutdown is being initialized and that the value of m_hEventShutdown isn't being changed, etc.If you run the debug build ouside of VC++ or by just pressing Ctrl-F5 then all is well.The same behavior is experienced with the release build. I'm curious to know why running inside the debugger exposes this. Maybe this is a debugger problem and has nothing to do with WTL? I'm running NT 4.0 SP5 and Visual Studio 6 SP3. -Scott Date: Fri, 28 Jan 2000 11:59:18 -0000 Hi. I am implementing an ATL dialog box containing an owner drawn list view control. My problem is that the dialog, which inherits from CAxDialogImpl, never receives the WM_DRAWITEM message. I also tried NM_CUSTOMDRAW with no success. I inserted a List Control into my dialog resource with the following styles:
LVS_REPORT | LVS_OWNERDRAWFIXED | LVS_NOCOLUMNHEADER | WS_BORDER | WS_TABSTOP
Here's what I do in the code:
//message map...
MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)
MESSAGE_HANDLER(WM_DRAWITEM,OnDrawItem)
COMMAND_ID_HANDLER(IDOK, OnOK)
COMMAND_ID_HANDLER(IDCANCEL, OnCancel)
//....
WTL::CListViewCtrl *m_ListCtrl;
Here's what I do in my OnInitDialog:
LRESULT CMyDlg::OnInitDialog(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL&
bHandled)
{
//....
m_ListCtrl = new WTL::CListViewCtrl(m_hWnd);
m_ListCtrl->GetDlgItem(IDC_MY_LIST);
//...
}
Also spying the messages sent both to the dialog and the list control I haven't seen any WM_DRAWITEM. Any ideas??? Thanks Giulio Date: Mon, 6 Mar 2000 12:12:32 -0500 Yes, CCommandBarCtrl is a hairy bugger. I have inserted a CCommandBarCtrl as band 0 of a CRebarCtrl. Then I insert another band without a RBBS_BREAK [so the two bands are on the same row, if there's room]. Then I call CRebarCtrl::MinimizeBand(0) [so any slack space on the row is used by band 1]. So far so good, but when I then increase the width of the window, band 0 grows to take up the slack. This is an unacceptable effect - band 0 was already the proper size. This must be a problem with CComandBarCtrl.When I substitute CToolBarCtrl for CCommandBarCtrl, the resized band 0 stays minimized - as expected. TIA for any ideas. Two followups - 1. Is there any support for a separate WTL discussion group or newsgroup? 2. When MS releases code unsupported and as-is, does that mean that MSDN developer support won't entertain incidents related to the code? From: "Crusader Mike" <[email protected]> Hi. Damn -- I already found one bug in WTL: CServerAppModule::m_hEventShutdown was 'CloseHandle'ed two times undersome circumstances. :( and application crashes on exit. Bye. Sincerely yours, Mike. Date: Sat, 11 Mar 2000 08:27:00 -0500 The wizard code for com servers calls:
// WTL::CServerAppModule::MonitorShutdown() line 494
::CloseHandle(m_hEventShutdown);
and then
// WTL::CServerAppModule::Term() line 455-456
if (m_hEventShutdown != NULL)
CloseHandle(m_hEventShutdown);
One of these calls has to go or - perhaps more robustly - both should be tested for NULL before being closed and set to NULL afterwards. Curiously, the kernel throws an exception only under the debugger ... t Date: Thu, 30 Mar 2000 09:22:45 -0000 CHAIN_MSG_MAP and templates (vc6.0 sp3) Yesterday I noticed something quite weird. To start I was having a look at desk bands and thought that it would be nice to have a WTL command bar in there. So I started of, but of course the wintraits class that CMainFrameImpl uses it not very suitable for a control so I used the one from CComControl (I think that was the one). Anyway my CMainFrameImpl had template parameters that were separated by commas. When I put this as an entry in the message map using CHAIN_MSG_MAP the compiler was not at all happy, it seemed to think that the template arguments were arguments for the #define. Luckily I have it working I had to typedef the declaration and it worked nicely. Thought I should let you guys know about that one, or has it already been found? best regards, and sorry about the printing scare Mike Date: Tue, 4 Apr 2000 13:11:27 +0100 Just for info The functions to select text and deselect text are the wrong. CEdit::SetSelNone - selects all the text in the edit control Antony From: Richard Tearle <[email protected]> I've come across a little bug in WTL, to do with Most Recently Used lists and Command Bars. The MRU will create a menu for you for all of the documents you have opened before. It uses the full path of the file (prefix with a number and a space). This is OK but the paths can get quite long and the command bar control has a limit of 100 characters for the menu text. A quick fix is to copy the CRecentDocumentList class, and modify the following function (Why oh why isn't the function I need to override ever virtual !!)
BOOL UpdateMenu()
{
...
#define MAX_MENU_PATH ( CCommandBarCtrl::_nMaxMenuItemTextLength - 4 )
TCHAR szItemText[MAX_MENU_PATH + 4]; // add space for &, 2 digits, and a
space
int nSize = m_arrDocs.GetSize();
nItem = 0;
if(nSize > 0)
{
TCHAR tmpBuffer [ MAX_MENU_PATH ] ;
for(nItem = 0; nItem < nSize; nItem++)
{
// this fix relies on <ShlWapi.h> in place
::PathCompactPathEx ( tmpBuffer, m_arrDocs[nSize - 1 -
nItem].szDocName, MAX_MENU_PATH, 0 ) ;
wsprintf ( szItemText, _T("&%i %s"), nItem + 1, tmpBuffer ) ;
::InsertMenu(m_hMenu, nInsertPoint + nItem, MF_BYPOSITION | MF_STRING,
ID_FILE_MRU_FIRST + nItem, szItemText);
}
}
...
}
if you look at the source code it's quite easy to find. Another fix I've come up with is not to select disabled menu items in a command bar, much like Office 97 but *not* like IE5.0. I think it looks better, here's the class:
class CCommandBarCtrl2 : public CCommandBarCtrlImpl<CCommandBarCtrl2>
{
public:
DECLARE_WND_SUPERCLASS(_T("WTL_CommandBar"), GetWndClassName())
BEGIN_MSG_MAP(CCommandBarCtrl2)
MESSAGE_HANDLER(WM_DRAWITEM, OnDrawItem)
CHAIN_MSG_MAP(CCommandBarCtrlImpl<CCommandBarCtrl2>)
ALT_MSG_MAP(1)
CHAIN_MSG_MAP_ALT(CCommandBarCtrlImpl<CCommandBarCtrl2>,1)
ALT_MSG_MAP(2)
CHAIN_MSG_MAP_ALT(CCommandBarCtrlImpl<CCommandBarCtrl2>,2)
ALT_MSG_MAP(3)
CHAIN_MSG_MAP_ALT(CCommandBarCtrlImpl<CCommandBarCtrl2>,3)
END_MSG_MAP()
LRESULT OnDrawItem(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM lParam, BOOL&
bHandled)
{
LPDRAWITEMSTRUCT lpDrawItemStruct = (LPDRAWITEMSTRUCT)lParam;
_MenuItemData* pmd = (_MenuItemData*)lpDrawItemStruct->itemData;
if(lpDrawItemStruct->CtlType == ODT_MENU && pmd->IsCmdBarMenuItem())
{
BOOL bDisabled = lpDrawItemStruct->itemState & ODS_GRAYED;
BOOL bSelected = lpDrawItemStruct->itemState & ODS_SELECTED;
BOOL bChecked = lpDrawItemStruct->itemState & ODS_CHECKED;
if ( bDisabled )
{
lpDrawItemStruct->itemState &= ~ODS_SELECTED ;
if ( ( lpDrawItemStruct->itemAction & ODA_SELECT ) ==
ODA_SELECT )
return TRUE ;
}
DrawItem ( lpDrawItemStruct ) ;
}
else
bHandled = FALSE;
return (LRESULT)TRUE;
}
} ;
Is there a better way of doing the message maps ?? Anyhow, hope this is of use to someone Richard. From: Paul Beaulieu " <[email protected]>
Hi, |
Contribute to IDR:
To contribute an article to IDR, a click here.
To contact us at IDevResource.com, use our feedback form, or email us. To comment on the site contact our webmaster. |
 | All content © Copyright 2000 IDevResource.com, Disclaimer notice |