Toolbar Icons Not Displaying

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.

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?

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,"

Is the app run on Vista ?  If yes did you experience the same problem on Win 2000 or XP ?

>>>> "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

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