Dirty toolbar icons?

Paul Mitchell -- mitchell.p@britishgas.co.uk
Tuesday, May 14, 1996


VC4.1/Win95

I have an MFC application which is based upon a CFrameWnd derived window
and has a toolbar.

everything has been fine until recently I installed the ActiveX SDK.  As
you may know this package
updates several system DLLs including COMMCTL32.DLL.

Now I find that many (not all) of the icons on my toolbar appear "dirty". 
They have a brown smear
across them.

No other application seems to be affected, just my one. Has anone else
seen this effect?  And more
to the point, how can I cure it?

Paul Mitchell
British Gas Plc.
--
----------------------
Paul Mitchell
British Gas Plc.

---

Dicky Singh -- Dicky@landmark.com
Wednesday, May 15, 1996

[Mini-digest: 5 responses]

You probably have an application that was created using AppWizard 2.2 or 
older.  Applications created with VC4.x. use LoadToolbar instead of 
LoadBitmap+SetButtons, and they show buttons correctly.  The preferred way 
to solve this to use LoadToolbar and convert your resource from BMP to a 
toolbar resource.  (See Help on how to do the latter)

Change Toolbar creation sequence to:

	if (!m_wndToolBar.Create(this) ||
		!m_wndToolBar.LoadToolBar(IDB_RR_TOOLBAR)){
		TRACE("Failed to create toolbar\n");
		return -1;
	}

-----------------------------
-Dicky
Dicky@Landmark.COM
Dragon Team

-----From: "Joseph M. Koral" 

You must have originally generated your app with MFC 3.x... =20

This is a bug in the new COMCTL32.DLL.  In a nutshell, the toolbar =
problem boils down to needing to explicitly call CToolBar::SetSizes or =
sending TB_SETBITMAPSIZE and TB_SETIMAGESIZE to the control.

I found it odd that this behavior changed between "releases", especially =
when you look at the documentation.  It explicitly states that setting =
the size of the image and buttons is only needed when you are using some =
non-default toolbar button sizes.  (Image 16,15 and Button 24,22). =20

However, I was told that the DLL shipping with ActiveX (and Internet =
News and Mail) was still a beta version, and this particular problem =
would be fixed.


>> No other application seems to be affected, just my one. Has anone =
else
>> seen this effect? =20

There are other apps affected.  For example, check out Spy++ or the MFC =
sample Superpad (samples\mfc\ole\superpad).  You'll also note that =
WordPad (which we *know* started with MFC 3.0) does not have this =
problem, they already have the explicit call to SetSizes in their =
toolbar creation.


>> And more to the point, how can I cure it?

If you originally generated your app with MFC 4.0, there is an implicit =
SetSizes within CToolBar::LoadToolBar.  However, this isn't present if =
you started with MFC 3.0, and you will need to explicitly call SetSizes.

MFC 3.0 generated code:

	if (!m_wndToolBar.Create(this) ||
		!m_wndToolBar.LoadBitmap(IDR_MAINFRAME) ||
		!m_wndToolBar.SetButtons(buttons,
		sizeof(buttons)/sizeof(UINT)))
	{
	        TRACE0("Failed to create toolbar\n");
	        return -1;      // fail to create
	}

MFC 4.0 generated code:

	if (!m_wndToolBar.Create(this) ||
		!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
	{
		TRACE0("Failed to create toolbar\n");
		return -1;      // fail to create
	}


So if you're code looks like the MFC 3.0 snippet above, following the =
comment in the MFC 4.0, LoadToolBar, you need to make the call to =
SetSizes *before* LoadBitmap:

	m_wndToolBar.SetSizes(CSize(23,22), CSize(16,15));

(FYI, these *are* the default sizes of the toolbar bitmaps and buttons =
according to the SDK.  It states the above call is not neccessary unless =
you are using non-standard sizes).


- Joseph

-----From: "Jeff Shanholtz" 

I have noticed something similar. I have MS Office 7.0 installed and, in case 
you're unfamiliar with it, the toolbar is actually a collection of toolbars, 
and you click on a button to make a given toolbar visible.

Well, the buttons that represent the toolbars are totally blank after 
installing the Active X developer's kit. I tried uninstalling it, but to no 
avail. It really ticked me off, although functionally everything works ok.

I, too, would like to know how to fix this (either by removing the cause or by 
upgrading something).

Jeff Shanholtz
Enertech Consultants

-----From: Brian Jones 

Yes, I have also experienced this problem, but I am running NT 4.0 Beta   
1.  I first noticed this problem when I tried to run an app I'm working   
on (after installing the ActiveX SDK).  It also appears when you run the   
MFC samples.  I did a temporary fix by doing a Repair install of NT,   
thinking it was a bug in the Beta version of NT, not the SDK.  Of course   
this solution removes the smooth scrolling and explorer underline,   
because it replaces the dlls the ActiveX SDK installed.

Brian Jones
Bremerton, WA

-----From: Luca Orlandi 

The same appened to mine ... I've just backd'up to the old =
COMMCTL32.DLL.. I hope it's MS's mistake in the alpha version of the =
product.

---

| Вернуться в корень Архива |