[RESOLVED] Unwanted Toolbar Button

This one's driving me nuts.

I now have an unwanted, disabled button on my program's toolbar that has an image that appears to be a ghost (disabled copy) of the first button's icon. The toolbar behaves normally, otherwise. All my attempts to remove or account for the button have failed. The attached image shows the program behavior at the top, the toolbar editor in the middle and the properties for the "next" icon at the bottom.

The development environment is Visual C++ 2017 (15.9.21). The program was originally developed under VS 6.0 and spent many years in VS 2005. However, the problem does not relate to the VS 2017 upgrade. That was accomplished two years ago.

Note that I don't have much experience with direct editing in the *.rc file, but I'm willing to have a go at that with proper guidance.

Thanks for any insight and/or assistance.

FF

Quote:

---

Originally Posted by FerroFun

This one's driving me nuts.

I now have an unwanted, disabled button on my program's toolbar that has an image that appears to be a ghost (disabled copy) of the first button's icon. The toolbar behaves normally, otherwise. All my attempts to remove or account for the button have failed. The attached image shows the program behavior at the top, the toolbar editor in the middle and the properties for the "next" icon at the bottom.

The development environment is Visual C++ 2017 (15.9.21). The program was originally developed under VS 6.0 and spent many years in VS 2005. However, the problem does not relate to the VS 2017 upgrade. That was accomplished two years ago.

Note that I don't have much experience with direct editing in the *.rc file, but I'm willing to have a go at that with proper guidance.

Thanks for any insight and/or assistance.

FF

---

It's probably in your MainFrm.cpp code. Look for an array called nButtons, and a call to m_wndToolBar.SetButtons(). If you don't see anything there, look for anything in MainFrm.cpp that has to to with initializing the toolbar.

Thanks for the suggestions. I am actually using a third-party library - Rogue Wave Stingray - to handle my windows. I pass a 0 count into the toolbar loading function. The library assigns the number of buttons - 17 - apparently when the toolbar is loaded. This is the correct number for the intended display if separators are included in the count. The actual display shows an additional separator and an additional button.

I will continue to tilt at this starting next Monday. For now it's time for a holiday weekend.

Thanks again.

FF

This has gotten even stranger to me. The Toolbar Editor and *.rc files seem to have no effect whatsoever on the toolbar.

I added a resource ID to the "next" button and did a quick icon. I added the resource to one of the program menus and added handlers. The second attached image ("Unwanted Toolbar Button 2") shows that the resource appears correctly in the menu when the resource is both enabled and disabled. The menu entry also properly calls the handler. However, the image shows that the toolbar remains unchanged.

In the third attached image I show that the toolbar design differs completely from the program behavior. I have moved the new resource to fourth from the left. I did this by directly editing the *.rc file as shown. The *.rc changes appear in the Toolbar Editor, but not in the executing toolbar. Furthermore, the separators are misplaced in the executing toolbar and, apparently have been for some time.

Even if there is some sort of bug in the Toolbar Editor, it seems to me that direct editing in the *.rc file should compile and display any changes.

Thanks for any suggestions.

FF

As I said earlier, the problem isn't likely in the resource file, it's where the toolbar is getting created. If you're using MFC, lookin in Mainfrm.cpp. If you're not, look into whatever framework is actually creating the toolbar.

Yes, this is an MFC project.

Your are most-likely correct. I will return my attention to code as soon as I clear a few other things out of the way.

Thanks,

FF

Does Rogue Wave Stingray handle the toolbar generation? If so, it might be good to post to their forum.

Thanks for the advise. I was going to do that next.

FF

I seem to have corrected this problem locally by using the customize dialog to adjust the toolbar within the program. This is persistent. If the adjusted arrangement appears in the distributed program, the problem resolved, even if not programmatically.

I am marking this as resolved

Uhm, how do I mark this as resolved?

In the toolbar above this thread press "button" Thread Tools and choose the context menu item Mark Thread Resolved