trishm
asked on
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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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?
Are you dynamically modifying the contents of the toolbar / menu when you launch the app?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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->AddToolBarRes
pToolBarMgr->LoadToolBarRe
pToolBarMgr->DefineDefault
fileButtons,CBRS_ALIGN_ANY
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,"
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->AddToolBarRes
pToolBarMgr->LoadToolBarRe
pToolBarMgr->DefineDefault
fileButtons,CBRS_ALIGN_ANY
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
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
ASKER
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
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
ASKER
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.