Toolbar Icons Not Displaying

Hello,
I'm working with an application developed using C++ and MFC. The toolbar icons associated with the MainFrame do not always display when you launch the app.

Users have reported that It seems to happen most often (but not always) when a new release is installed. They say that deleting the registry and relaunching the app fixes the problem.

Also, users report that at times, the toolbar icon appears to be enabled, but hovering over the image does not display the tool tip. Then, when clicked, the button does not respond.

I haven't been able to duplicate this problem in my development environment nor have I established a solid pattern to the symptoms reported.

I don't have a specific question to ask but I could use some help on how to begin to fix this.

Thank you in advance.
trishm

trishmAsked:
Who is Participating?
 
itsmeandnobodyelseCommented:
>>>> The toolbar icons associated with the MainFrame do
>>>> not always display when you launch the app.
The only reason that fits to all that you told is that your app is doing some 'idle' job while initializing but fails at these machines for any reason (network, lack of resources, not freeing handles, ...).  Hence the icons sometimes were not shown (if the idle job runs before first painting) or do not respond (if the idle job runs after displaying the icons). To verifiy that theory you would need to watch the issue personally. You may then put the mouse at one of the icons and wait (maybe minutes). If the tooltip finally comes your prog simply was busy and therefore the low responseness. Check the Taskmanager whether your prog (or any other prog) uses 100 % cpu.  

>>>> They say that deleting the registry and relaunching the app fixes the problem.
You should make an export of the registry (best NT4.0 reg files) before and after that operation. Check the differences with WinDiff (or any other file compare tool). Maybe some path was written wrongly by the setup program.

Regards, Alex


0
 
AndyAinscowFreelance programmer / ConsultantCommented:
Check the resource ID's - sounds like there could be some problems with duplicate IDs.  Especially if the app comes with 'home made' dll's
0
 
trishmAuthor Commented:
Another symptom reported:

The main menu options "File"  "View"  etc. don't respond to a mouse click.
Using the Hot Keys, Alt-F, always works.
I'm running the same app and the same OS (XP) but not experiencing this problem.

AndyAinscow:
I'll look into the resource ID's. Thanks.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
AndyAinscowFreelance programmer / ConsultantCommented:
The only other thing that springs to mind is the question
Are you dynamically modifying the contents of the toolbar / menu when you launch the app?
0
 
trishmAuthor Commented:
AndyAinscow:

Yes. The toolbar is created when the app is launched. The creation method follows the method prescribed in "Programming Windows with MFC". The difference is that the toolbar-creation classes are MFC exension classes provided by "Objective Toolkit". I've provided information on this library at the bottom of this comment.

1)  First, arrays are created for each segment of the toolbar:

static UINT BASED_CODE fileButtons[] =
{
     ID_EDIT_CUT,
     ID_EDITCOPY,
     ID_EDIT_PASTE
};
. . . .  other button arrays ...

2)  The following code adds/loads the toolbar resource and button resource IDs.

CMainFrame::OnCreate( ... )
{
     pToolBarMgr->AddToolBarResource(MAKEINTRESOURCE(IDR_MAINFRAME));
     pToolBarMgr->LoadToolBarResource()

     pToolBarMgr->DefineDefaultToolBar(AFX_IDW_TOOLBAR,_T("File"),NUMELEMENTS(fileButtons),
          fileButtons,CBRS_ALIGN_ANY,AFX_IDW_DOCKBAR_TOP);

This code (and supporting library) has been in use for some time and has been successful. We've had one version upgrade since. I haven't worked with this code long enough to determine if the new version introduced bugs.

-------------------------------------------------
itsmeandnobodyelse:

Thank you for you comment. Your reason seems to fit.

The MFC book I have states that "the framework calls the update handler during idle periods in which there are no messages for the application to process. The physical calling mechanism is transparent to the application, which simply provides an update handler and then trusts the framework to call it as needed."

I will run further tests and watch the CPU utilization.

----------------------------
Objective Toolkit

"Objective Toolkit is a set of MFC extension classes that enhance your current Visual C++/Microsoft Foundation Class programs. Objective Toolkit provides support for a variety of graphical user interface controls, views, and utilities. You can extend its object-oriented classes quickly and easily.

Unlike other C++ class libraries, Objective Toolkit classes are completely compatible with the Microsoft Foundation Class (MFC) classes. The Objective Toolkit classes work seamlessly with the MFC classes and, in many cases, inherit from existing classes such as CView or CWnd.

Objective Toolkit is fully compatible with the latest 32-bit releases of Visual C++, including Visual C++ 6.0 and VC.NET.

Objective Toolkit components enable you to dedicate your efforts to creating a viable
application, instead of modifying the GUI,"
0
 
AndyAinscowFreelance programmer / ConsultantCommented:
Is the app run on Vista ?  If yes did you experience the same problem on Win 2000 or XP ?
0
 
itsmeandnobodyelseCommented:
>>>> "the framework calls the update handler during idle periods in which there are no messages for the application to process. The physical calling mechanism is transparent to the application, which simply provides an update handler and then trusts the framework to call it as needed."

Unfortunately, they didn't tell in that 'ad' that the idle handler - like any other handler - can do only very short things before return or it would block the whole message pump. The pump is a infinite loop like

     while (PeekMessage(Msg, ....))
     {
             GetMessage(Msg, ...);
             TranslateMessage(Msg, ...);
             DispatchMessage(Msg, ...);
     }

That kind of loop let all windows programs run. Your handlers will be called with 'DispatchMessage' and if one of them makes any lengthy operation, the whole pump was hold on (the screen freezes). Your idle handler was called if the queue was empty, i. e. the PeekMessage doesn't find a message to process. And of course that idle handler runs synchronously, i. e. it blocks the messaging if it for example have to wait for a network devie to respond.

The way out is either to split up a lengthy action into small short actions, e. g. run each time the handler was called only one iteration of a lengthy loop, or to create a thread and let it do the job really asynchronously.

Regards, Alex
0
 
trishmAuthor Commented:
Experts:
Thank you for your comments. You've given me some things to think about and look into.
Any further questions I have, I will post as new.

trishm
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.