|
Stephen Hewitt wrote: Maybe another module called SetUnhandledExceptionFilter and replaced your handler but isn't calling yours
How do we detect that? How do find out the currently set unhandled exception filters, if any?
Stephen Hewitt wrote: It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE
Actually, it used to work earlier. Due to some changes this regressed. I only need tips to debug this.
Stephen Hewitt wrote: You could place a breakpoint inside SetUnhandledExceptionFilter and check for this.
As I said I already have a message box as the first statement in SetUnhandledExceptionFilter filter, and that doesnt come up. So I am assuming my filter isnt called at all 
thanks!
|
|
|
|
|
Brundiez wrote: How do we detect that? How do find out the currently set unhandled exception filters, if any?
I would use WinDBG as follows:
1. Start the process in question.
2. Type "bp kernel32!SetUnhandledExceptionFilter" in the command window.
3. Press F5.
4. When the breakpoint is hit look at the stack.
5. Goto step 3
This will show every call to SetUnhandledExceptionFilter made in the process. I would only pay attention to breakpoints that occur after your call to SetUnhandledExceptionFilter.
Steve
|
|
|
|
|
Hi,
I have a SDI application that I show a CListCtrl-derived control using the LVS_ICON style with a 24-bit color imagelist filled with 80x80 bitmaps to represent the items in the control. When I select an item in the control, it doesn't select properly. Only the text of the item is selected and it is gray as if the control doesn't have the focus. But the control does in fact have the focus. Why doesn't the item select properly, i.e., with a blue background?
Any help would be greatly appreciated,
Royce
-- modified at 12:47 Monday 23rd January, 2006
|
|
|
|
|
RoyceF wrote: I have a SDI application that I show a CListCtrl-derived control...
Are you using a CListView?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
No, the parent of the control is the CFormView created by the CSingleDocTemplate constructor when the application is created.
|
|
|
|
|
To ascertain whether it is the actual list control or the parent object (CFormView) causing the problem, I would suggest creating a temporary dialog-based project that contains the same sort of list control. Populate the list control in exactly the same fashion. Does it behave the same as the one in the SDI project?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Ok, I did as you suggest. I get exactly the same behavior. The items select just the text and are a dim gray.
|
|
|
|
|
I could post my test project, but I don't know if the forum would appreciate a 130 Kbyte post.
|
|
|
|
|
Can you supply a screenshot of the offending control?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
How do I post a bitmap or GIF?
|
|
|
|
|
You can't. You'll have to find a Web site that will allow such. There are a ton of them out there that can act as a repository.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
|
Are you sure the ListCtrl still has focus?
You might try setting up an WM_KILLFOCUS handler for the list control and running it in the debugger or something. It sounds like the control has actually lost focus, which might not be apparent because if you click on it again it temporarily gets focus, handles your click on the item, and then possibly loses focus again.
Good luck!
Mike Stephenson
|
|
|
|
|
I have already tried exactly what you suggest. The control is not losing the focus.
Thanks for your help.
|
|
|
|
|
First, I'd double-verify that it's not losting focus by clicking on the control, then clicking on another control and making sure that the OnKillFocus handler is actually being called when I expect it to (it's possible depending on your message maps and parent/child relationships that the view is eating the messages).
If that plays out, and you're confident that the control truly is not losing focus, could it be a problem with transparency of your images in the image list and the background color of the text (and the text not being transparent), simply not letting the blue "show through"?
|
|
|
|
|
Yes, I have just verified that the control is not losing focus when it should not. Its OnSetFocus() and OnKillFocus() handlers are being called appropriately. When I select an item, the OnSetFocus() handler is called. The OnKillFocus() handler is not being called until I actually do move the focus. I have used different types & sizes of bitmaps and different parameters in creating the imagelist, but no change in the control's behavior.
|
|
|
|
|
When you select an item using the mouse, different from the that is selected by default, does it appear in blue, or grey?
|
|
|
|
|
Selected by any means, it is always gray.
|
|
|
|
|
I have just built a version of my test project using a CScrollView as the parent of the CListCtrl. It exhibits the same behavior as the dialog-based app and the CFormView-based app. That would seem to point to the images or the ImageList object that I am using. However, I have used this same ImageList & bitmaps in another project, but the selection behavior is correct.
|
|
|
|
|
Just to be safe, does explorer highlight in blue when you select a file? Its possible to have your "scheme" have the highlight color set to gray.
As another thought, is your ListView (or ListCtrl) derived from anything, meaning did you use a class from an outside source? Just wondering if perhaps you or that class might be using NM_CUSTOMDRAW to override painting.
Also, what styles are being used on the view, single selection, full-row selection, show selection always, owner data, owner draw?
Personally I've never seen a basic ListCtrl ever paint incorrectly without some kind of interference from code.
|
|
|
|
|
Yes, Explorer highlights in blue, as it always has. Also, a TreeCtrl in my app which is a sibling of my ListCtrl selects correctly with a blue highlight.
|
|
|
|
|
Oh, um, are you using a manifest under VC6? I know when you use manifests (to get the XP style look), imagelists behave differently. I think, but not certain by any means, that the newer compilers handle this without problems, but I'm fairly sure VC6 won't. I've found CImageList won't work quite right, I had to use the macros like ImageList_Create for it to work right.
|
|
|
|
|
No, I am using VC7 unmanaged code.
|
|
|
|
|
VC7 has an option during project creation for including a manifest for C++ apps that defaults to "ON". Check your project or project/res directory for a .manifest file. If you have one, then its probably being used. Try turning it off.
|
|
|
|
|
How do I do that? My test app project has a manifest file, but my real project does not. With both projects exhibiting the same behavior, one has a manifest and the other does not, I can't believe that is the problem. Anyway, I can't find a setting in the project configuration for turning it on or off. I also searched the vcproj file for a hidden setting.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
